Thread: [Fwd: [PORTS] Port Bug Report: parse error not detected on unterminated quote]
[Fwd: [PORTS] Port Bug Report: parse error not detected on unterminated quote]
From
Thomas Lockhart
Date:
(back on list)
Bruce, the problem is revealed with the "single-line input" mode of
psql. I'm a bit suprised that the backend parser doesn't catch this,
but I see why now: scan.l goes into a "string accumulate" mode when it
sees a single quote, and doesn't actually send a token back to gram.y
until it sees the closing quote. If EOT comes first, then there is no
flag to tell gram.y (or whatever is the right thing) that there is
still an active token being worked on.
Not certain yet how to fix this; the "string accumulator" is currently
local to scan.l and I'm not sure if scan.l can provide code to check
this after it runs out of characters to process. I do have a lex/yacc
book, but if anyone has some hints...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, CaliforniaThomas Lockhart wrote:
> > Problem Description:
> > --------------------
> > If a single quote is left unmatched in the query, the parser
> > seems to throw away the rest of the line without detecting
> > an error.
> > Test Case:
> > ----------
> > Enter a select like this:
> > select * from mytable where id = 1234;
> > You should get only one record.
> >
> > Now put in an errant single quote:
> > select * from mytable' where id = 1234;
> > Now you get the whole table. This should really be a
> > syntax error of some kind.
>
> And seems to be:
>
> postgres=> select * from mytable' where id = 1234;
> postgres'> '
> postgres-> ;
> ERROR: parser: parse error at or near "'"
> postgres=>
>
> This is on a RH5.2 system with with the cvs distribution of Postgres
> (rather than v6.5 exactly). But the parsing behavior should be the
> same. I'm not sure what could be different in our installations...
>
> - Thomas
>
> --
> Thomas Lockhart lockhart@alumni.caltech.edu
> South Pasadena, California
Yup, it seems to be OK in psql interactive mode. The problem only shows
up if I type:
psql mydb -c "select * from mytable' where id = 1234;"
--
----------------------------------------------------
Kyle Bateman President, Action Target Inc.
"Viva Yo!" kyle@actarg.com (801)377-8033x101
----------------------------------------------------
Re: [Fwd: [PORTS] Port Bug Report: parse error not detected on unterminated quote]
From
Bruce Momjian
Date:
> (back on list) > > Bruce, the problem is revealed with the "single-line input" mode of > psql. I'm a bit suprised that the backend parser doesn't catch this, > but I see why now: scan.l goes into a "string accumulate" mode when it > sees a single quote, and doesn't actually send a token back to gram.y > until it sees the closing quote. If EOT comes first, then there is no > flag to tell gram.y (or whatever is the right thing) that there is > still an active token being worked on. > > Not certain yet how to fix this; the "string accumulator" is currently > local to scan.l and I'm not sure if scan.l can provide code to check > this after it runs out of characters to process. I do have a lex/yacc > book, but if anyone has some hints... I seem to remember there is a function you can define to be called on EOF in scan.l. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Re: [Fwd: [PORTS] Port Bug Report: parse error not detected on unterminated quote]
From
Bruce Momjian
Date:
Seems this bug still exists. > (back on list) > > Bruce, the problem is revealed with the "single-line input" mode of > psql. I'm a bit suprised that the backend parser doesn't catch this, > but I see why now: scan.l goes into a "string accumulate" mode when it > sees a single quote, and doesn't actually send a token back to gram.y > until it sees the closing quote. If EOT comes first, then there is no > flag to tell gram.y (or whatever is the right thing) that there is > still an active token being worked on. > > Not certain yet how to fix this; the "string accumulator" is currently > local to scan.l and I'm not sure if scan.l can provide code to check > this after it runs out of characters to process. I do have a lex/yacc > book, but if anyone has some hints... > > - Thomas > > -- > Thomas Lockhart lockhart@alumni.caltech.edu > South Pasadena, California -- Start of included mail From: Kyle Bateman <kyle@actarg.com> > Sender: kyle@actarg.com > Date: Wed, 30 Jun 1999 08:38:10 -0600 > Organization: Action Target Inc > X-Accept-Language: en > To: Thomas Lockhart <lockhart@alumni.caltech.edu> > Subject: Re: [PORTS] Port Bug Report: parse error not detected on unterminated > quote > X-Mozilla-Status2: 00000000 > Thomas Lockhart wrote: > > > > Problem Description: > > > -------------------- > > > If a single quote is left unmatched in the query, the parser > > > seems to throw away the rest of the line without detecting > > > an error. > > > Test Case: > > > ---------- > > > Enter a select like this: > > > select * from mytable where id = 1234; > > > You should get only one record. > > > > > > Now put in an errant single quote: > > > select * from mytable' where id = 1234; > > > Now you get the whole table. This should really be a > > > syntax error of some kind. > > > > And seems to be: > > > > postgres=> select * from mytable' where id = 1234; > > postgres'> ' > > postgres-> ; > > ERROR: parser: parse error at or near "'" > > postgres=> > > > > This is on a RH5.2 system with with the cvs distribution of Postgres > > (rather than v6.5 exactly). But the parsing behavior should be the > > same. I'm not sure what could be different in our installations... > > > > - Thomas > > > > -- > > Thomas Lockhart lockhart@alumni.caltech.edu > > South Pasadena, California > > Yup, it seems to be OK in psql interactive mode. The problem only shows > up if I type: > > psql mydb -c "select * from mytable' where id = 1234;" > > -- > ---------------------------------------------------- > Kyle Bateman President, Action Target Inc. > "Viva Yo!" kyle@actarg.com (801)377-8033x101 > ---------------------------------------------------- > > -- End of included mail. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
I can confirm this is fixed in 7.0. (I am in mailbox cleaning mode.) > (back on list) > > Bruce, the problem is revealed with the "single-line input" mode of > psql. I'm a bit suprised that the backend parser doesn't catch this, > but I see why now: scan.l goes into a "string accumulate" mode when it > sees a single quote, and doesn't actually send a token back to gram.y > until it sees the closing quote. If EOT comes first, then there is no > flag to tell gram.y (or whatever is the right thing) that there is > still an active token being worked on. > > Not certain yet how to fix this; the "string accumulator" is currently > local to scan.l and I'm not sure if scan.l can provide code to check > this after it runs out of characters to process. I do have a lex/yacc > book, but if anyone has some hints... > > - Thomas > > -- > Thomas Lockhart lockhart@alumni.caltech.edu > South Pasadena, California -- Start of included mail From: Kyle Bateman <kyle@actarg.com> > Sender: kyle@actarg.com > Date: Wed, 30 Jun 1999 08:38:10 -0600 > Organization: Action Target Inc > X-Accept-Language: en > To: Thomas Lockhart <lockhart@alumni.caltech.edu> > Subject: Re: [PORTS] Port Bug Report: parse error not detected on unterminated > quote > X-Mozilla-Status2: 00000000 > Thomas Lockhart wrote: > > > > Problem Description: > > > -------------------- > > > If a single quote is left unmatched in the query, the parser > > > seems to throw away the rest of the line without detecting > > > an error. > > > Test Case: > > > ---------- > > > Enter a select like this: > > > select * from mytable where id = 1234; > > > You should get only one record. > > > > > > Now put in an errant single quote: > > > select * from mytable' where id = 1234; > > > Now you get the whole table. This should really be a > > > syntax error of some kind. > > > > And seems to be: > > > > postgres=> select * from mytable' where id = 1234; > > postgres'> ' > > postgres-> ; > > ERROR: parser: parse error at or near "'" > > postgres=> > > > > This is on a RH5.2 system with with the cvs distribution of Postgres > > (rather than v6.5 exactly). But the parsing behavior should be the > > same. I'm not sure what could be different in our installations... > > > > - Thomas > > > > -- > > Thomas Lockhart lockhart@alumni.caltech.edu > > South Pasadena, California > > Yup, it seems to be OK in psql interactive mode. The problem only shows > up if I type: > > psql mydb -c "select * from mytable' where id = 1234;" > > -- > ---------------------------------------------------- > Kyle Bateman President, Action Target Inc. > "Viva Yo!" kyle@actarg.com (801)377-8033x101 > ---------------------------------------------------- > > -- End of included mail. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026