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

On Mon, Oct 24, 2016 at 5:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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>.
>

Thank you, I missed that rule.

It's not consistent with this rule:

SQL text containing one or more instances of <comment> is equivalent to the
same SQL text with the
<comment> replaced with <newline>.

and I certainly agree on the rest, about the explicit syntax:

>
> 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
>