From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function |
Date: | 2010-01-09 20:28:11 |
Message-ID: | 15985.1263068891@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com> writes:
> 2010/1/9 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com> writes:
>>> I wonder if it might be better to have plpgsql_parse_dblword() ignore
>>> plpgsql_LookupIdentifiers, and always do the lookups.
>> Not if you'd like things to still work.
> OK, I admit that I'm totally new that area of code, so I'm not seeing
> it - what does it break?
The main problem is it will throw errors in some cases where that's
premature. For instance we might have a.x where a is a plpgsql
row variable that doesn't contain x ... but if the reference is
in a query where a is a table that contains x, and we are using
prefer-the-column rules, this is not an error case. Also we do
not want any lookups while looking at DECLARE constructs ---
it doesn't matter whether there's an outer-scope variable of the
same name.
However, it turns out my solution isn't working too well either :-(.
I can make it work for some of the system columns, but not for xmin,
xmax, or cmin/cmax because those fields of a regular tuple are overlaid
with datum-tuple header fields. So by the time ExecEvalFieldSelect gets
the tuple those values are irretrievably trashed.
I think that a variant of your idea could be made to work: change
plpgsql_LookupIdentifiers to a three-state variable (which'd basically
mean "in DECLARE, in a SQL expression, anywhere else"), do no lookups in
DECLARE, and in SQL expressions do lookups but never throw any errors.
I'll have a go at that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marcin Mańk | 2010-01-09 20:44:38 | Re: synchronized snapshots |
Previous Message | Dean Rasheed | 2010-01-09 20:09:22 | Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function |