"Axel at ansonic" <goddyna@ansonic.com.au> writes:
> reedited the file, take the line break out of it with one backspace (taking
> out asci char 10)
> Note asci char 13 still lives in the file, and is invisible.
> Compiling is ok.
> After executing the cgi PQtrace tells me:"ERROR: parser: parse error at or
> near ""
Hmm. It looks like scan.l already thinks \r is whitespace,
*except* in the situation where you're trying to continue a literal
string across lines, eg.
INSERT INTO table VALUES('some data' 'some more data');
If the intermediate end-of-line is only \r and hasn't got a \n,
the lexer will spit up because its rule for collapsing out the
two quotes and intervening whitespace is
xqcat {quote}{space}*\n{space}*{quote}
If there's not a genuine honest-to-god \n in there, you lose.
My question to the lex gurus: why doesn't this rule simply read
xqcat {quote}{space}*{quote}
considering that both \r and \n are members of {space}? In fact,
shouldn't xqdouble and xqcat be combined and defined as above?
Unless lex has some weird built-in special treatment of \n,
I don't see why we need to call it out explicitly.
Similar comments apply to xbcat and xhcat --- and I'm kind of
wondering about xqliteral, xcline, and xcstop, all of which seem
to accord undeserved special status to \n ...
regards, tom lane
