Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA98972 for ; Mon, 7 Feb 2000 22:52:52 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA27737; Mon, 7 Feb 2000 22:51:16 -0500 (EST) To: "Axel at ansonic" cc: pgsql-interfaces@postgreSQL.org, "Ross J. Reedstrom" , blackw@sfu.ca Subject: Re: [INTERFACES] Bug in parser? In-reply-to: References: Comments: In-reply-to "Axel at ansonic" message dated "Tue, 08 Feb 2000 12:47:22 +1100" Date: Mon, 07 Feb 2000 22:51:16 -0500 Message-ID: <27734.949981876@sss.pgh.pa.us> From: Tom Lane "Axel at ansonic" 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