Re: [INTERFACES] Bug in parser?

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Axel at ansonic <goddyna(at)ansonic(dot)com(dot)au>, pgsql-interfaces(at)postgreSQL(dot)org, "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>, blackw(at)sfu(dot)ca
Subject: Re: [INTERFACES] Bug in parser?
Date: 2000-02-08 06:06:51
Message-ID: 389FB27B.1F9702BD@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

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

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.

But perhaps a somewhat more general rule would work, allowing \r \c
and \n as line break characters??

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Tom Lane 2000-02-08 06:42:13 Re: [INTERFACES] Bug in parser?
Previous Message Tom Lane 2000-02-08 03:51:16 Re: [INTERFACES] Bug in parser?