SQL Reserved Key Words Checker Tool
Updated on February 26, 2024
By Pete Freitag
By Pete Freitag
I just whipped together a tool for checking for reserved sql words. The tool checks against SQL Server 2000, MySQL 5.0, PostgreSQL 8.0, Oracle 10g, ODBC, and SQL Server Future Keywords list.
It is a good idea to make sure you db schema's will work ok across multiple db platforms, so the tool will show you which platforms a word is reserved on.
If you find that tool helpful, be sure to take a look at some of my other blog entries, such as how to select a random row with SQL or finding duplicates with SQL.
SQL Reserved Key Words Checker Tool was first published on March 28, 2005.
If you like reading about sql, databases, postgresql, mysql, sqlserver, or oracle then you might also like:
- SELECT a random row with SQL
- Order by NULL Values in MySQL, Postgresql and SQL Server
- INFORMATION_SCHEMA Support in MySQL, PostgreSQL
- Returning TOP N Records
Discuss / Follow me on Twitter ↯
Tweet Follow @pfreitagComments
Thanks Ovidiu, I have updated it, I was missing a few new keywords in mysql 5.
by Pete Freitag on 03/28/2006 at 10:21:04 AM UTC
Hi,
just tried out your checker. I guess what it really needs is to get the information dynamically so the checker is always uptodate. That being said things like "GROUP" are probably a reserved word in any RDBMS since ages, but does not show up as reserved in all RDBMS in your checker.
just tried out your checker. I guess what it really needs is to get the information dynamically so the checker is always uptodate. That being said things like "GROUP" are probably a reserved word in any RDBMS since ages, but does not show up as reserved in all RDBMS in your checker.
by Lukas on 07/09/2006 at 2:53:31 AM UTC
Lukas, Yes that would be nice to have it dynamically updated, but hey it just a free tool.
As for GROUP not being reserved in some RDBMS's -- the way I use the tool is if a word is reserved on any RDBMS I avoid using it in my schema. Even if I'm using MySQL and it's reserved in Oracle, I like to avoid it, incase the server is ever moved to Oracle.
As for GROUP not being reserved in some RDBMS's -- the way I use the tool is if a word is reserved on any RDBMS I avoid using it in my schema. Even if I'm using MySQL and it's reserved in Oracle, I like to avoid it, incase the server is ever moved to Oracle.
by Pete Freitag on 07/09/2006 at 10:36:16 PM UTC
Yeah, I checked "GROUP" and its not listed as reserved in MySQL, eventhough its been reserved since forever. Thats what I wanted to point out.
BTW: I am the lead author of PEAR::MDB2_Schema, which essentially is a frontend to manage a database schema in an independent format (currently the only format supported is an xml schema format). One of the cool features is that it can check the identifiers against lists of reserved words.
Anyways I will try if I can establish a standard for publishing reserved words lists in the open source database world.
BTW: I am the lead author of PEAR::MDB2_Schema, which essentially is a frontend to manage a database schema in an independent format (currently the only format supported is an xml schema format). One of the cool features is that it can check the identifiers against lists of reserved words.
Anyways I will try if I can establish a standard for publishing reserved words lists in the open source database world.
by Lukas on 07/10/2006 at 12:48:45 AM UTC
The keyword list for PostgreSQL is too large.
Keywords in the PostgreSQL grammar are divided into several groups, and the so-called "unreserved" keywords are actually available for use as table or column names, or in any other context as any non-keyword is. The grammar needs them as keywords because they're used in some non-ambiguous context, but for an application, there is no disinction between an unreserved keyword and a word that's not a keyword at all. For example, "CHECKPOINT" is an unreserved keyword because there's a CHECKPOINT command to perform a checkpoint, but you can create a table called CHECKPOINT or column with no problem.
An up-to-date list of keywords can be found at http://www.postgresql.org/docs/8.4/interactive/sql-keywords-appendix.html. You should ignore all the keywords listed as "non-reserved" (or blank). Even better, you could distinguish the classes of "reservedness" in the tool, but you should leave out the non-reserved ones anyway.
Keywords in the PostgreSQL grammar are divided into several groups, and the so-called "unreserved" keywords are actually available for use as table or column names, or in any other context as any non-keyword is. The grammar needs them as keywords because they're used in some non-ambiguous context, but for an application, there is no disinction between an unreserved keyword and a word that's not a keyword at all. For example, "CHECKPOINT" is an unreserved keyword because there's a CHECKPOINT command to perform a checkpoint, but you can create a table called CHECKPOINT or column with no problem.
An up-to-date list of keywords can be found at http://www.postgresql.org/docs/8.4/interactive/sql-keywords-appendix.html. You should ignore all the keywords listed as "non-reserved" (or blank). Even better, you could distinguish the classes of "reservedness" in the tool, but you should leave out the non-reserved ones anyway.
by Heikki Linnakangas on 10/29/2009 at 12:18:52 PM UTC