Re: Out parameters handling - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Out parameters handling
Date
Msg-id 18247.1236463735@sss.pgh.pa.us
Whole thread Raw
In response to Re: Out parameters handling  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Out parameters handling  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

> 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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Out parameters handling
Next
From: Alvaro Herrera
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Redefine _() to dgettext() instead of gettext() so that it uses