So I was testing the next step of plpgsql modification, namely actually
letting the parser hooks do something, and it promptly blew up in
trigger functions, like so:

+ ERROR: OLD used in query that is not in a rule
+ LINE 1: SELECT OLD
+ ^
+ QUERY: SELECT OLD
+ CONTEXT: SQL statement in PL/PgSQL function "trigger_data" near line 35

The reason is that because plpgsql is no longer translating references
to its names into Params before letting the core parser see them, the
kluge in gram.y that changes "OLD" to "*OLD*" and "NEW" to "*NEW*"
kicks in, or actually decides to throw an error instead of kicking in.

I am wondering what is the point at all of having that kluge. It
certainly doesn't manage to make OLD/NEW not act like reserved words,
in fact rather more the opposite, as shown here. If we just made those
names be ordinary table alias names in rule queries, wouldn't things
work as well or better?

BTW, this brings up another point, which is that up to now it's often
been possible to use plpgsql variable names that conflict with
core-parser reserved words, so long as you didn't need to use the
reserved word with its special meaning. That will stop working when
this patch goes in. Doesn't bother me any, but if anyone thinks it's
a serious problem, speak now.

regards, tom lane

Search Discussions

  • Kevin Grittner at Nov 5, 2009 at 10:11 pm

    Tom Lane wrote:

    been possible to use plpgsql variable names that conflict with
    core-parser reserved words, so long as you didn't need to use the
    reserved word with its special meaning. That will stop working when
    this patch goes in. Doesn't bother me any, but if anyone thinks it's
    a serious problem, speak now.
    As long as I can use anything I want when it's quoted, I don't care.

    -Kevin
  • Robert Haas at Nov 6, 2009 at 1:03 am

    On Thu, Nov 5, 2009 at 4:33 PM, Tom Lane wrote:
    So I was testing the next step of plpgsql modification, namely actually
    letting the parser hooks do something, and it promptly blew up in
    trigger functions, like so:

    + ERROR:  OLD used in query that is not in a rule
    + LINE 1: SELECT  OLD
    +                 ^
    + QUERY:  SELECT  OLD
    + CONTEXT:  SQL statement in PL/PgSQL function "trigger_data" near line 35

    The reason is that because plpgsql is no longer translating references
    to its names into Params before letting the core parser see them, the
    kluge in gram.y that changes "OLD" to "*OLD*" and "NEW" to "*NEW*"
    kicks in, or actually decides to throw an error instead of kicking in.

    I am wondering what is the point at all of having that kluge.  It
    certainly doesn't manage to make OLD/NEW not act like reserved words,
    in fact rather more the opposite, as shown here.  If we just made those
    names be ordinary table alias names in rule queries, wouldn't things
    work as well or better?

    BTW, this brings up another point, which is that up to now it's often
    been possible to use plpgsql variable names that conflict with
    core-parser reserved words, so long as you didn't need to use the
    reserved word with its special meaning.  That will stop working when
    this patch goes in.  Doesn't bother me any, but if anyone thinks it's
    a serious problem, speak now.
    Any keyword or just fully reserved keywords?

    ...Robert
  • Tom Lane at Nov 6, 2009 at 6:03 am

    Robert Haas writes:
    BTW, this brings up another point, which is that up to now it's often
    been possible to use plpgsql variable names that conflict with
    core-parser reserved words, so long as you didn't need to use the
    reserved word with its special meaning.  That will stop working when
    this patch goes in.  Doesn't bother me any, but if anyone thinks it's
    a serious problem, speak now.
    Any keyword or just fully reserved keywords?
    Anything that's not allowed as a column name will be at issue.

    regards, tom lane
  • Robert Haas at Nov 6, 2009 at 12:23 pm

    On Fri, Nov 6, 2009 at 1:02 AM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.com> writes:
    BTW, this brings up another point, which is that up to now it's often
    been possible to use plpgsql variable names that conflict with
    core-parser reserved words, so long as you didn't need to use the
    reserved word with its special meaning.  That will stop working when
    this patch goes in.  Doesn't bother me any, but if anyone thinks it's
    a serious problem, speak now.
    Any keyword or just fully reserved keywords?
    Anything that's not allowed as a column name will be at issue.
    Well, that's not so bad. If it included unreserved keywords I think
    that would be more of an issue.

    ...Robert
  • Roberto Mello at Nov 6, 2009 at 12:06 pm

    On Thu, Nov 5, 2009 at 5:33 PM, Tom Lane wrote:
    BTW, this brings up another point, which is that up to now it's often
    been possible to use plpgsql variable names that conflict with
    core-parser reserved words, so long as you didn't need to use the
    reserved word with its special meaning.  That will stop working when
    this patch goes in.  Doesn't bother me any, but if anyone thinks it's
    a serious problem, speak now.
    I imagine there will be a small percentage of PL/pgSQL users that will
    be afected, so these changes must be well written up in the PL/pgSQL
    documentation.

    Roberto
  • David Fetter at Nov 7, 2009 at 7:11 am

    On Thu, Nov 05, 2009 at 04:33:07PM -0500, Tom Lane wrote:
    So I was testing the next step of plpgsql modification, namely actually
    letting the parser hooks do something, and it promptly blew up in
    trigger functions, like so:

    + ERROR: OLD used in query that is not in a rule
    + LINE 1: SELECT OLD
    + ^
    + QUERY: SELECT OLD
    + CONTEXT: SQL statement in PL/PgSQL function "trigger_data" near line 35

    The reason is that because plpgsql is no longer translating references
    to its names into Params before letting the core parser see them, the
    kluge in gram.y that changes "OLD" to "*OLD*" and "NEW" to "*NEW*"
    kicks in, or actually decides to throw an error instead of kicking in.

    I am wondering what is the point at all of having that kluge. It
    certainly doesn't manage to make OLD/NEW not act like reserved words,
    in fact rather more the opposite, as shown here. If we just made those
    names be ordinary table alias names in rule queries, wouldn't things
    work as well or better?

    BTW, this brings up another point, which is that up to now it's often
    been possible to use plpgsql variable names that conflict with
    core-parser reserved words, so long as you didn't need to use the
    reserved word with its special meaning. That will stop working when
    this patch goes in. Doesn't bother me any, but if anyone thinks it's
    a serious problem, speak now.
    Sorry to be late on this :(

    There's been a suggestion, to be filled in later, that
    UPDATE...RETURNING be able to return (expressions on) columns from
    both the old row and the new one. The syntax would involve either
    using OLD to specify old rows, or both NEW and OLD if we want to break
    current behavior. Would this make that easier to do? Harder? Is it
    orthogonal?

    Cheers,
    David (who thinks that both NEW and OLD are object names so poor we
    should force quoting them just on aesthetic principle ;)
    --
    David Fetter <david@fetter.org> http://fetter.org/
    Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
    Skype: davidfetter XMPP: david.fetter@gmail.com
    iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

    Remember to vote!
    Consider donating to Postgres: http://www.postgresql.org/about/donate
  • Josh Berkus at Nov 8, 2009 at 5:33 pm
    Tom,
    BTW, this brings up another point, which is that up to now it's often
    been possible to use plpgsql variable names that conflict with
    core-parser reserved words, so long as you didn't need to use the
    reserved word with its special meaning. That will stop working when
    this patch goes in. Doesn't bother me any, but if anyone thinks it's
    a serious problem, speak now.
    Sounds like a potential *big* blocker to upgrading; anyone with several
    thousand lines of plpgsql can't really afford to refactor away all of
    the accidental uses of reserved words.

    That being said, reusing reserved words in this way was always wonky, so
    I'm not sure how many people will have done so. Best way is to commit
    it to alpha3, and try to get people to test.

    --Josh Berkus

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 5, '09 at 9:33p
activeNov 8, '09 at 5:33p
posts8
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase