Re: Out parameters handling

On Sat, Mar 7, 2009 at 5:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I think that would definitely be an improvement.  Would that mean that
>> in a query like the following:
>
>> SELECT t.id FROM test t WHERE t.id = 17
>
>> ...it wouldn't consider replacing "t"?  That all by itself would be an
>> improvement...
>
> It's already the case that plpgsql knows enough to not replace "t"
> in the context "t.something".  But I suppose you are talking about the
> alias declaration.  Yeah, that should get better if we push this into
> the main parser.

+1 from me then.

>> I actually feel like the best thing to do would be to error out if
>> there's an ambiguous reference.  If you write this:
>> SELECT id FROM foo, bar WHERE foo.a = bar.a
>> ...it will complain if both foo.id and bar.id are defined.  So if I write:
>> SELECT id FROM foo
>> ...shouldn't it complain if both foo.id and <parameter namespace>.id
>> are defined?
>
> No, on the principle that more closely nested definitions take
> precedence.  The reason the first example merits an error is that the
> two possible sources of the name have equal precedence.

That's reasonable, but I'm not a huge fan. The fact that host and
guest variables live in the same namespace is a huge source of bugs.
Your idea above is an improvement IMO but I wish there were some way
to make it airtight.

...Robert