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
|
Список | 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 по дате отправления: