FAQ
(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

Search Discussions

  • Bruce Momjian at Jul 1, 1999 at 4:43 am

    (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
  • Bruce Momjian at Nov 29, 1999 at 10:44 pm
    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
  • Bruce Momjian at May 31, 2000 at 9:05 pm
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedJun 30, '99 at 3:05p
activeMay 31, '00 at 9:05p
posts4
users3
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase