On Sat, Mar 7, 2009 at 5:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
