From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | Christoph Haller <ch(at)rodos(dot)fzk(dot)de>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: " Adding missing FROM-clause entry for table .... " problem. |
Date: | 2003-02-18 15:50:25 |
Message-ID: | 23770.1045583425@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> Christoph Haller <ch(at)rodos(dot)fzk(dot)de> wrote:
>> AFAIK, statements like
>> DELETE FROM t1 where t1.id = t2.id ;
>> are legal. Could the parser still work on this, if the feature is
>> removed?
> Only if a new syntax is added.
For UPDATE, we actually do have an extension syntax that allows naming
secondary tables explicitly:
UPDATE target SET ... FROM other-tables WHERE ...
The trouble with extending this to DELETE is that DELETE already uses
the keyword FROM. Seems like we are stuck with a choice between
DELETE FROM target FROM other-tables WHERE ...
DELETE FROM target, other-tables WHERE ...
both of which are bizarre and confusing to my eyes. I think that MySQL
uses the second form, which I like even less than the first (it obscures
the very fundamental semantic difference between the deletion target and
the other tables).
Or we could go off with a different keyword, perhaps
DELETE FROM target WITH other-tables WHERE ...
but that doesn't seem to pass the low-astonishment test either.
Comments? It would not be difficult to implement any of these
alternatives. <hhg>okay, you think it's so easy, *you* decide
what color it should be</hhg>
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Eckermann | 2003-02-18 16:03:10 | Re: " Adding missing FROM-clause entry for table .... " problem. |
Previous Message | Tom Lane | 2003-02-18 15:40:10 | Re: " Adding missing FROM-clause entry for table .... " problem. |