Are there multiline comment delimiters in SQL that

Question

While editing, building up, or cherry picking from SQL statements I can find myself interacting with one of four popular database tools. I have been resorting to single line commenting for DB2 and Informix. I have created macros in vim to make this slightly more efficient but I was wondering if I am working too hard.

Answer 1

The ISO standard only defines single-line comments beginning with two dashes. Some vendors support C-style commenting (i.e. multiline beginning with /* and ending with */), but it should not be considered "vendor agnostic".

Answer 2

C style comments are standard in SQL 2003 and SQL 2008 (but not in SQL 1999 or before). The following DBMS all support C style comments:

• Informix
• PostgreSQL
• MySQL
• Oracle
• DB2
• Sybase
• Ingres
• Microsoft SQL Server
• SQLite (3.7.2 and later)
• Teradata and Aster

That is not every possible DBMS, but it is more or less every major SQL DBMS. (I'll willingly add notes about any other DBMS that does - or does not - support C style comments.)

The SQL 2003 standard documents comment notations thus:

<comment> ::= <simple comment> | <bracketed comment>

<simple comment> ::=
    <simple comment introducer> [ <comment character> ... ] <newline>

<simple comment introducer> ::=
    <minus sign> <minus sign> [ <minus sign> ... ]

<bracketed comment> ::=
    <bracketed comment introducer> <bracketed comment contents>
    <bracketed comment terminator>

<bracketed comment introducer> ::= <slash> <asterisk>

<bracketed comment terminator> ::= <asterisk> <slash>

<bracketed comment contents> ::= [ { <comment character> | <separator> }... ]

<comment character> ::= <nonquote character> | <quote>

IBM Informix Dynamic Server (IDS or Informix) supports C style comments. It also supports '{ ... }' as potentially multi-line comments, except in contexts where it means something else - that something else being a LIST or SET or MULTISET literal. (You might find that DB-Access gets confused by C style comments; that is a separate issue.)