On Sat, Mar 7, 2009 at 5:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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
