Re: [INTERFACES] Bug in parser?

"Axel at ansonic" <goddyna(at)ansonic(dot)com(dot)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