Skip site navigation (1) Skip section navigation (2)

Re: aliases break my query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Joseph Shraibman <jks(at)selectacast(dot)net>, "pgsql-sql(at)postgresql(dot)org" <pgsql-sql(at)postgreSQL(dot)org>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: aliases break my query
Date: 2000-05-26 16:26:06
Message-ID: 2392.959358366@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-sql
Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE> writes:
> Once again, I think that we *really* need to discuss whether implicit
> range table entries in SELECT are a good idea. We invariably get a
> question like this every week and invariably the answer is "if you give a
> table an alias you *must* refer to it by that alias". (I'm sure Tom has
> this reply automated by now.)

No, this one was actually a pretty original way of shooting oneself in
the foot ;-).  I thought the interesting point was the confusion between
whether variables in the inner select were supposed to be local to the
inner select or references to the outer select.  I'm not sure getting
rid of implicit rangetable entries would've helped prevent that.

> I claim the only thing that buys is
> confusion for very little convenience at the other end.
>
> Stop the madness! :)

I doubt that it's worth breaking a lot of existing applications for.

At one time Bruce had made some patches to emit informative notice
messages about implicit FROM entries, but that got turned off again
for reasons that I forget...

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Joseph ShraibmanDate: 2000-05-26 17:47:03
Subject: Re: aliases break my query
Previous:From: Tom LaneDate: 2000-05-26 16:12:55
Subject: Re: SPI & file locations

pgsql-sql by date

Next:From: Ed LoehrDate: 2000-05-26 16:35:35
Subject: Re: POSTGRESQL and PERL?
Previous:From: Tom LaneDate: 2000-05-26 16:19:52
Subject: Re: PG/DBI: 'NOTICE: UserAbortTransactionBlock and not in in-progress state'

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group