Re: Re: [SQL] 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: Zeugswetter Andreas <andreas(dot)zeugswetter(at)telecom(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [SQL] aliases break my query
Date: 2000-05-26 22:42:03
Message-ID: 3941.959380923@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> "Emit a notice [or error if you insist] when an implicit FROM item is
>> added that refers to the same underlying table as any existing FROM
>> item."

> That's a step in the right direction, but I'd still like to catch
> SELECT a.a1, b.b1 FROM a;
> SELECT a.a1 FROM a WHERE a.a2 = b.b1;
> both of which are more or less obviously incorrect and easily fixed.

More or less obviously nonstandard, you mean. It's unlikely that
either of those examples are incorrect in the sense of not doing what
the user expected them to.

If we were working in a green field then I'd agree that we ought to be
100% SQL-spec-compliant on this point. But as is, we are talking about
rejecting an extension that Postgres has always had and a lot of people
find useful. I'm not eager to do that; I think it'd be putting pedantry
ahead of usefulness and backwards-compatibility. What I want to see is
the minimum restriction that will catch likely errors, not an "I'll
annoy you until you change your queries to meet the letter of the spec"
kind of message.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Joseph 2000-05-26 23:00:10 where is libpq-fe.h
Previous Message Peter Eisentraut 2000-05-26 22:30:14 Re: Re: [SQL] aliases break my query

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2000-05-26 22:48:04 Re: [SQL] is limit a reserved keyword?
Previous Message Peter Eisentraut 2000-05-26 22:30:14 Re: Re: [SQL] aliases break my query