Re: [INTERFACES] Bug in parser?

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Pretty sure that the SQL92 rules for the "string across lines" is more
> restrictive than just allowing spaces between double quotes; you
> actually need something close to a line break.
>
> select * from "T1" "A1";
>
> would do horrible things if I interpret your suggestion correctly.

No, because we're talking about string literals (single quotes) not
double-quoted names.  Is there harm in interpretingselect 'a string' ' literal';
asselect 'a string literal';
?  And if so, why does it suddenly become OK if I write it asselect 'a string'       ' literal';

The SQL92 spec isn't particularly transparent about this, but if I am
looking at the right syntax items, we have
        <character string literal> ::=             [ <introducer><character set specification> ]             <quote> [
<characterrepresentation>... ] <quote>               [ { <separator>... <quote> [ <character representation>... ]
<quote>}... ]
 
        <separator> ::= { <comment> | <space> | <newline> }...

which sure as heck looks like you can write either newline or just
plain space between 'a string' and ' literal' and get the same answer.

A couple other items:

* I see why xqdouble has to be separate from xqcat; the former
produces a single quote in the represented string, the latter doesn't.
So xqcat must at least be defined asxqcat    {quote}{space}{space}*{quote}
to allow it to be distinguished from xqdouble.

* I see that the spec allows comments between segments of a string
literal.  This works in current code:

regression=# select 'a string' -- zzz
regression-# ' literal';    ?column?
------------------a string literal
(1 row)

but I'm durned if I see where that behavior is implemented.
Do you?
        regards, tom lane