pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedBug in parser?
12+ messages / 6 participants
[nested] [flat]
* Bug in parser?
@ 2000-02-05 00:37 Richard <blackw@sfu.ca>
0 siblings, 1 reply; 12+ messages in thread
From: Richard @ 2000-02-05 00:37 UTC (permalink / raw)
To: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-05 02:20 Ed Loehr <eloehr@austin.rr.com>
parent: Richard <blackw@sfu.ca>
0 siblings, 1 reply; 12+ messages in thread
From: Ed Loehr @ 2000-02-05 02:20 UTC (permalink / raw)
To: blackw@sfu.ca; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-07 16:28 Richard <blackw@sfu.ca>
parent: Ed Loehr <eloehr@austin.rr.com>
0 siblings, 1 reply; 12+ messages in thread
From: Richard @ 2000-02-07 16:28 UTC (permalink / raw)
To: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-07 17:17 Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
parent: Richard <blackw@sfu.ca>
0 siblings, 1 reply; 12+ messages in thread
From: Ross J. Reedstrom @ 2000-02-07 17:17 UTC (permalink / raw)
To: Richard <blackw@sfu.ca>; +Cc: pgsql-interfaces
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
>
> ************
>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-07 17:59 Richard <blackw@sfu.ca>
parent: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
0 siblings, 1 reply; 12+ messages in thread
From: Richard @ 2000-02-07 17:59 UTC (permalink / raw)
To: ; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-07 18:46 Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
parent: Richard <blackw@sfu.ca>
0 siblings, 2 replies; 12+ messages in thread
From: Ross J. Reedstrom @ 2000-02-07 18:46 UTC (permalink / raw)
To: Richard <blackw@sfu.ca>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-07 20:13 Richard <blackw@sfu.ca>
parent: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
1 sibling, 0 replies; 12+ messages in thread
From: Richard @ 2000-02-07 20:13 UTC (permalink / raw)
To: ; +Cc: pgsql-interfaces
"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
^ permalink raw reply [nested|flat] 12+ messages in thread
* RE: [INTERFACES] Bug in parser?
@ 2000-02-08 01:47 Axel at ansonic <goddyna@ansonic.com.au>
parent: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
1 sibling, 1 reply; 12+ messages in thread
From: Axel at ansonic @ 2000-02-08 01:47 UTC (permalink / raw)
To: pgsql-interfaces; +Cc: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>; blackw@sfu.ca
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
>
> ************
>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-08 03:51 Tom Lane <tgl@sss.pgh.pa.us>
parent: Axel at ansonic <goddyna@ansonic.com.au>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2000-02-08 03:51 UTC (permalink / raw)
To: Axel at ansonic <goddyna@ansonic.com.au>; +Cc: pgsql-interfaces@postgreSQL.org, "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>; blackw@sfu.ca
"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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-08 06:06 Thomas Lockhart <lockhart@alumni.caltech.edu>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Lockhart @ 2000-02-08 06:06 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Axel at ansonic <goddyna@ansonic.com.au>; pgsql-interfaces@postgreSQL.org, "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>; blackw@sfu.ca
> 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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-08 06:42 Tom Lane <tgl@sss.pgh.pa.us>
parent: Thomas Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2000-02-08 06:42 UTC (permalink / raw)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>; +Cc: Axel at ansonic <goddyna@ansonic.com.au>; pgsql-interfaces@postgreSQL.org, "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>; blackw@sfu.ca
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 interpreting
select 'a string' ' literal';
as
select 'a string literal';
? And if so, why does it suddenly become OK if I write it as
select '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> [ <character representation>... ] <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 as
xqcat {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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [INTERFACES] Bug in parser?
@ 2000-02-08 07:13 Thomas Lockhart <lockhart@alumni.caltech.edu>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Thomas Lockhart @ 2000-02-08 07:13 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Axel at ansonic <goddyna@ansonic.com.au>; pgsql-interfaces@postgreSQL.org, "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>; blackw@sfu.ca
> * 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
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2000-02-08 07:13 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2000-02-05 00:37 Bug in parser? Richard <blackw@sfu.ca>
2000-02-05 02:20 ` Ed Loehr <eloehr@austin.rr.com>
2000-02-07 16:28 ` Richard <blackw@sfu.ca>
2000-02-07 17:17 ` Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
2000-02-07 17:59 ` Richard <blackw@sfu.ca>
2000-02-07 18:46 ` Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
2000-02-07 20:13 ` Richard <blackw@sfu.ca>
2000-02-08 01:47 ` Axel at ansonic <goddyna@ansonic.com.au>
2000-02-08 03:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2000-02-08 06:06 ` Thomas Lockhart <lockhart@alumni.caltech.edu>
2000-02-08 06:42 ` Tom Lane <tgl@sss.pgh.pa.us>
2000-02-08 07:13 ` Thomas Lockhart <lockhart@alumni.caltech.edu>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox