Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA24035 for ; Tue, 8 Feb 2000 00:58:55 -0500 (EST) (envelope-from lockhart@alumni.caltech.edu) Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1]) by localhost (8.8.7/8.8.7) with ESMTP id GAA04294; Tue, 8 Feb 2000 06:06:51 GMT Sender: lockhart@hub.org Message-ID: <389FB27B.1F9702BD@alumni.caltech.edu> Date: Tue, 08 Feb 2000 06:06:51 +0000 From: Thomas Lockhart X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tom Lane CC: Axel at ansonic , pgsql-interfaces@postgreSQL.org, "Ross J. Reedstrom" , blackw@sfu.ca Subject: Re: [INTERFACES] Bug in parser? References: <27734.949981876@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > 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@alumni.caltech.edu South Pasadena, California