Re: BUG #14394: No error raised in IN-clause when commas are missing

Pantelis Theodosiou <ypercube@gmail.com> writes:
> On Mon, Oct 24, 2016 at 3:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Two string constants that are only separated by whitespace *with
>> at least one newline* are concatenated and effectively treated as
>> if the string had been written as one constant.

> I agree but shouldn't it run without errors when there is no newline (on=
ly
> spaces or comments) as well?

No, because then the syntax rule that causes the literals to be merged
into a single literal doesn't apply, so you get a syntax error.

> Which version of the standard has this  "at least one newline"?

All of them.  SQL92 for instance says (see 5.2 <token> and <separator>
and 5.3 <literal>):

         <separator> ::=3D { <comment> | <space> | <newline> }...

         <character string literal> ::=3D
              [ <introducer><character set specification> ]
              <quote> [ <character representation>... ] <quote>
                [ { <separator>... <quote> [ <character representation>...=
 ] <quote> }... ]

         1) In a <character string literal> or <national character string
            literal>, the sequence:

              <quote> <character representation>... <quote>
              <separator>... <quote> <character representation>... <quote>

            is equivalent to the sequence

              <quote> <character representation>... <character representa-
              tion>... <quote>

         4) In a <character string literal>, <national character string
            literal>, <bit string literal>, or <hex string literal>, a <se=
p-
            arator> shall contain a <newline>.

The intent of allowing separators at all is evidently to allow very long
literals to be split across lines.  Which is fine, but I wish they'd
used some explicit syntax to specify continuation.  The existing
definition is pretty error-prone, as you found out.

            regards, tom lane