Re: Out parameters handling

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.

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

regards, tom lane