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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: BUG #14394: No error raised in IN-clause when commas are missing
Дата
Msg-id CAKFQuwas7TB+NrZEbom8x4LUNP5Ymhqo5LjGs2Eg98a3kvHOSA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #14394: No error raised in IN-clause when commas are missing  (Pantelis Theodosiou <ypercube@gmail.com>)
Ответы Re: BUG #14394: No error raised in IN-clause when commas are missing  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-bugs
On Mon, Oct 24, 2016 at 10:14 AM, Pantelis Theodosiou <ypercube@gmail.com>
wrote:

>
>
> 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> ::=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 strin=
g
>>             literal>, the sequence:
>>
>>               <quote> <character representation>... <quote>
>>               <separator>... <quote> <character representation>... <quot=
e>
>>
>>             is equivalent to the sequence
>>
>>               <quote> <character representation>... <character represent=
a-
>>               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.
>

=E2=80=8BTo restate part of the above: <separator> can be a single newline;
otherwise any multi-character=E2=80=8B sequence must contain (end with?) a =
new
line.  <'pre' /* comment */ 'post'> doesn't qualify for #1 since the
comment does not include a newline.


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

=E2=80=8B=E2=80=8BOur docs state we (effectively...) replace comments with =
a single
space...is this (or can it cause) an incompatibility?

https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-=
SYNTAX-COMMENTS

David J.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Pantelis Theodosiou
Дата:
Сообщение: Re: BUG #14394: No error raised in IN-clause when commas are missing
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #14394: No error raised in IN-clause when commas are missing