Thread: Bug in parser?
I have a program that executes the following command:
UPDATE ActiveUser SET status=-1 WHERE (datetime('today'::date, 'now'::time) - lastrequest) > timespan('10
minutes'::reltime)
("lastrequest" is of type "datetime")
When executed via ExecCommandOk(), I get the following error message
back from ErrorMessage():
parser: parser error at or near ""
However, if I cut this command from the terminal window in which the
program is running (the command string is dumped to stdout just before
execution), and paste it in psql, it executes just fine.
Does this appear to be a bug in the libpq++ library? Am I using SQL
incorrectly here? Something else, maybe?
Thanks in advance.
Cheers,
Richard
Richard wrote:
>
> UPDATE ActiveUser SET status=-1
> WHERE (datetime('today'::date, 'now'::time) - lastrequest) >
> timespan('10 minutes'::reltime)
>
> parser: parser error at or near ""
>
> Does this appear to be a bug in the libpq++ library? Am I using SQL
> incorrectly here? Something else, maybe?
A guess: try spaces around your '=' operator...that one sometimes
doesn't like being crowded...
Cheers,
Ed Loehr
Thanks, but nope... didn't help.
Cheers,
Richard
Ed Loehr wrote:
>
> Richard wrote:
> >
> > UPDATE ActiveUser SET status=-1
> > WHERE (datetime('today'::date, 'now'::time) - lastrequest) >
> > timespan('10 minutes'::reltime)
> >
> > parser: parser error at or near ""
> >
> A guess: try spaces around your '=' operator...that one sometimes
> doesn't like being crowded...
>
> Cheers,
> Ed Loehr
Richard -
I recently tripped over some whitespace sensitivity (that shouldn't be
there!) involving line-endings in queries. Could you try your UPDATE all
on one line, and see if that solves it? I haven't been able to replicate
my problem with my current set up (in order to file a bug report). It
originally happened with a demo system we had set up at a meeting. Once
we got back to the office, everything worked fine, of course!
We got the same sort of 'paser error at or near ""' line in the log,
but when I looked with the right editor, I say that there was a control
character (either ^M or ^R, can't remember which) between the quotes.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
On Mon, Feb 07, 2000 at 08:28:23AM -0800, Richard wrote:
> Thanks, but nope... didn't help.
>
> Cheers,
> Richard
>
> Ed Loehr wrote:
> >
> > Richard wrote:
> > >
> > > UPDATE ActiveUser SET status=-1
> > > WHERE (datetime('today'::date, 'now'::time) - lastrequest) >
> > > timespan('10 minutes'::reltime)
> > >
> > > parser: parser error at or near ""
> > >
> > A guess: try spaces around your '=' operator...that one sometimes
> > doesn't like being crowded...
> >
> > Cheers,
> > Ed Loehr
>
> ************
>
Bingo! I erased the SQL command and typed it on one line. Works find. Broke it up again with linefeeds. STILL WORKS! Now I wish I had commented-out the original command rather than replacing it, as now I don't know what the rogue character was! Grrrrrr! (I need more sleep!) Thanks for your help. And thanks to Axel too, who e-mailed me directly suggesting the same thing. Cheers, Richard "Ross J. Reedstrom" wrote: > > Richard - > I recently tripped over some whitespace sensitivity (that shouldn't be > there!) involving line-endings in queries. Could you try your UPDATE all > on one line, and see if that solves it? I haven't been able to replicate > my problem with my current set up (in order to file a bug report). It > originally happened with a demo system we had set up at a meeting. Once > we got back to the office, everything worked fine, of course! > > We got the same sort of 'paser error at or near ""' line in the log, > but when I looked with the right editor, I say that there was a control > character (either ^M or ^R, can't remember which) between the quotes. > > Ross
On Mon, Feb 07, 2000 at 09:59:06AM -0800, Richard wrote: > Bingo! > > I erased the SQL command and typed it on one line. Works find. Broke > it up again with linefeeds. STILL WORKS! > > Now I wish I had commented-out the original command rather than > replacing it, as now I don't know what the rogue character was! > Grrrrrr! (I need more sleep!) Ah, this means you can't reproduce it either? I was hoping you might be able to get a reproducible case, so we could get this bug stomped for 7.0 beta. Any chance the query was coming from a file that might have been edited from a Win32 mount/share? I think that's what triggered it for us. Ross > > Thanks for your help. And thanks to Axel too, who e-mailed me directly > suggesting the same thing. > > Cheers, > Richard > -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
"Ross J. Reedstrom" wrote:Ah, this means you can't reproduce it either? I was hoping you might > be able to get a reproducible case, so we could get this bug stomped for > 7.0 beta. Any chance the query was coming from a file that might have been > edited from a Win32 mount/share? I think that's what triggered it for us. > > Ross Quite likely; over the past month or so I have shuffled code between NT and Linux, usually via samba and FTP, and have had my Linux home directory mounted as a drive on my NT box. It is possible that one or more transfers took place without the proper translation enabled, or I edited a file across a mount. I'll have to play with this to see if I can reproduce the problem. Another lister has written to me directly and has had the same thing happen. He edited part of his code using Windows, and part using Linux and found CRLF characters embedded in his files. Replacing the CRLF cleared up the problem for him. (If he wants to jump into this thread to provide more details, I'm sure he will, but it is my policy not to public mention names of people who e-mail me privately). Cheers, Richard
Hi there, For ones I can say I can (reproduce an error, it seems to be my talent) I did write some cgi code in c with a select statement in notepad to be executed with PQexec. I broke the line with enter (entering asci char 13 & 10) then tranfered the code to unix 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 "" regards Axel > -----Original Message----- > From: owner-pgsql-interfaces@postgreSQL.org > [mailto:owner-pgsql-interfaces@postgreSQL.org]On Behalf Of Ross J. > Reedstrom > Sent: Tuesday, 8 February 2000 5:46 > To: Richard > Cc: pgsql-interfaces@postgreSQL.org > Subject: Re: [INTERFACES] Bug in parser? > > > On Mon, Feb 07, 2000 at 09:59:06AM -0800, Richard wrote: > > Bingo! > > > > I erased the SQL command and typed it on one line. Works find. Broke > > it up again with linefeeds. STILL WORKS! > > > > Now I wish I had commented-out the original command rather than > > replacing it, as now I don't know what the rogue character was! > > Grrrrrr! (I need more sleep!) > If you don't have much time to sleep, sleep faster...? > Ah, this means you can't reproduce it either? I was hoping you might > be able to get a reproducible case, so we could get this bug stomped for > 7.0 beta. Any chance the query was coming from a file that might have been > edited from a Win32 mount/share? I think that's what triggered it for us. > > Ross > > > > > Thanks for your help. And thanks to Axel too, who e-mailed me directly > > suggesting the same thing. > > > > Cheers, > > Richard > > > > -- > Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> > NSBRI Research Scientist/Programmer > Computer and Information Technology Institute > Rice University, 6100 S. Main St., Houston, TX 77005 > > ************ >
Hi, I have postgres 6.5 running on Linux (slackware 3.6). I tried upgrading to version 6.5.3, but i was not able to do it. It shows me something like this which i don't understand: make[2]: Leaving directory `/usr/src/pgsql/postgresql-6.5.3/src/interfaces/ecpg' make -C libpq++ all make[2]: Entering directory `/usr/src/pgsql/postgresql-6.5.3/src/interfaces/libpq++' gcc -I../../backend -I../../include -I../../interfaces/libpq -I../../include -I. ./../backend -O2 -Wall -Wmissing-prototypes -fpic -c pgconnection.cc -o pgconnection.o In file included from pgconnection.cc:20: pgconnection.h:24: string: No such file or directory make[2]: *** [pgconnection.o] Error 1 make[2]: Leaving directory `/usr/src/pgsql/postgresql-6.5.3/src/interfaces/libpq ++' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/pgsql/postgresql-6.5.3/src/interfaces' make: *** [all] Error 2 What's wrong with this, i don't encounter any problem in version 6.5. By the way, i use this command in configuring postgres: configure --with-perl --with-odbc Please help, thanks... George
"Axel at ansonic" <goddyna@ansonic.com.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
> 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
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> 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.
No, because we're talking about string literals (single quotes) not
double-quoted names. Is there harm in interpretingselect 'a string' ' literal';
asselect 'a string literal';
? And if so, why does it suddenly become OK if I write it asselect 'a string' ' literal';
The SQL92 spec isn't particularly transparent about this, but if I am
looking at the right syntax items, we have
<character string literal> ::= [ <introducer><character set specification> ] <quote> [
<characterrepresentation>... ] <quote> [ { <separator>... <quote> [ <character representation>... ]
<quote>}... ]
<separator> ::= { <comment> | <space> | <newline> }...
which sure as heck looks like you can write either newline or just
plain space between 'a string' and ' literal' and get the same answer.
A couple other items:
* I see why xqdouble has to be separate from xqcat; the former
produces a single quote in the represented string, the latter doesn't.
So xqcat must at least be defined asxqcat {quote}{space}{space}*{quote}
to allow it to be distinguished from xqdouble.
* I see that the spec allows comments between segments of a string
literal. This works in current code:
regression=# select 'a string' -- zzz
regression-# ' literal'; ?column?
------------------a string literal
(1 row)
but I'm durned if I see where that behavior is implemented.
Do you?
regards, tom lane
> * I see that the spec allows comments between segments of a string
> literal. This works in current code:
> regression=# select 'a string' -- zzz
> regression-# ' literal';
> ?column?
> ------------------
> a string literal
> (1 row)
> but I'm durned if I see where that behavior is implemented.
> Do you?
It used to be implemented in psql, and might still. Looks to me that
scan.l might be missing this case (which presumably you are thinking
also).
I'm still recalling the "line break" reasoning for concatenating
literals, but maybe that was just an example from the Date book rather
than the entire rule.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California