Dean Rasheed <dean.a.rash...@googlemail.com> writes:
> 2010/1/9 Tom Lane <t...@sss.pgh.pa.us>:
>> Dean Rasheed <dean.a.rash...@googlemail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
