Prev: [COMMITTERS] pgsql: Tidy up and refactor plperl.c.
Next: [HACKERS] Congrats Alvaro!
From: Tom Lane on 9 Jan 2010 15:28
Dean Rasheed <dean.a.rasheed(a)googlemail.com> writes:
> 2010/1/9 Tom Lane <tgl(a)sss.pgh.pa.us>:
>> Dean Rasheed <dean.a.rasheed(a)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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Dean Rasheed on 9 Jan 2010 15:53
2010/1/9 Tom Lane <tgl(a)sss.pgh.pa.us>:
>> 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...

Ah OK. Thanks for the explanation.

> 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.
>

Sounds plausible.

Cheers,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 10 Jan 2010 12:57
Dean Rasheed <dean.a.rasheed(a)googlemail.com> writes:
> 2010/1/9 Tom Lane <tgl(a)sss.pgh.pa.us>:
>> 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.

> Sounds plausible.

I've applied a patch along these lines.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Dean Rasheed on 10 Jan 2010 15:29
2010/1/10 Tom Lane <tgl(a)sss.pgh.pa.us>:
>
> I've applied a patch along these lines.
>

Cool. Thanks, that works great.

Cheers,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2
Prev: [COMMITTERS] pgsql: Tidy up and refactor plperl.c.
Next: [HACKERS] Congrats Alvaro!