Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function

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

In response to

Responses

Browse pgsql-hackers by date

  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