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@sss.pgh.pa.us> wrote:

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