From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: plpgsql and qualified variable names |
Date: | 2007-07-14 23:10:34 |
Message-ID: | 25734.1184454634@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> ISTM supporting "somefunc.ambiguous" just gives us another way to
> reference the parameter, and there still isn't any way to refer the column.
Sure. All this will do is let us remove a noted incompatibility with
Oracle, which seems worth doing if it's a one-line change that doesn't
break anything.
Further down the road, we could imagine some option in plpgsql that
prevents substitution of variables *unless* they are qualified with
the appropriate block name --- in which case we'd better make sure
there is a way to qualify function parameter names. So this might
be a necessary component of a solution that tightens up the
substitution behavior, but it's not the solution by itself.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Affan Salman | 2007-07-14 23:13:41 | Re: plpgsql and qualified variable names |
Previous Message | Andrew Dunstan | 2007-07-14 23:07:15 | Re: plpgsql FOR loop doesn't guard against strange step values |