From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why do OLD and NEW have special internal names? |
Date: | 2009-11-20 03:35:23 |
Message-ID: | 4B060E7B.2010703@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/5/2009 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?
Sorry, I don't recall what the exact point back then, when plpgsql was
created for 6.WHAT_VERSION, really was.
But this brings up another point about the recent discussion of what
RENAME is good for. Removing RENAME may conflict with using OLD/NEW in
UPDATE ... RETURNING. No?
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-11-20 03:55:39 | Re: operator exclusion constraints |
Previous Message | Jan Wieck | 2009-11-20 03:28:11 | Re: AFTER triggers & RETURN |