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