learn | unlearn | relearn

Almost all of us are probably dealing with databases each and every day. What I am seeing all the time is that people are using keywords for their field-names, for instance “date”.

Depending on the database brand you are using there are different kind of reserved (or not reserved) keywords the database is using itself. Reserved once can technically not be used as a field-name, the non-reserved once can be used (but are likely to cause challenges in more complex queries).

Here for instance the list in postgres:

SQL Key Words

Non-reserved keywords might become tricky if you might change your database one day. What is a non-reserved keyword on database “A” might very well be a reserved keyword on a different database “B”. Or the list might change in future :-(.

In principle you have 2 options:

  • Avoid those keywords
  • Using your own non conflicting taxonomy.

The latter ist quite easy, just use your own prefix for instance. Putting a simple f for field, or whatever comes in your mind, in front of every column-name is an easy trick to avoid any future conflict. You can as well make it more sophisticated and make these prefixes more “complex”. For instance prefix integer with i, t timestamps, d for dates … of course you can as well use 2 or 3 characters as a prefix — just take care to always apply the same rules.

Unless you are calling your column for date ‘ate’ and then prefixing it with a ‘d’ you will never run into any issues with keywords ;-).


Sign in or become a jeannot-muller.com member to join the conversation.
Just enter your email below to get a log in link.

You’ve successfully subscribed to jeannot-muller.com
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Your link has expired
Success! Check your email for magic link to sign-in.