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

Pantelis Theodosiou <ypercube(at)gmail(dot)com> writes:
> On Mon, Oct 24, 2016 at 3:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 (only
> 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> ::= { <comment> | <space> | <newline> }...

<character string literal> ::=
[ <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 <sep-
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