Re: [SQL] Efficient DELETE Strategies - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [SQL] Efficient DELETE Strategies
Date
Msg-id 200206101648.g5AGmG419376@candle.pha.pa.us
Whole thread Raw
In response to Re: [SQL] Efficient DELETE Strategies  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Christoph Haller <ch@rodos.fzk.de> writes:
> 
>     DELETE FROM relation_expr [ FROM table_ref [ , ... ] ]
>     [ WHERE bool_expr ]
> 
> The two FROMs in the second form look a little weird, but they help to
> make a clear separation between the deletion target table and the
> merely-referenced tables.  Also, the first one might look to people
> like they'd be allowed to write
> 
>     DELETE FROM foo FULL JOIN bar ...
> 
> which is not any part of my intention (it's very unclear what it'd
> mean for the target table to be on the nullable side of an outer join).
> OTOH there'd be no harm in outer joins in a separate from-clause, eg
> 
>     DELETE FROM foo FROM (bar FULL JOIN baz ON ...) WHERE ...
> 
> Actually, either syntax above would support that; I guess what's really
> bothering me about the first syntax is that a comma suggests a list of
> things that will all be treated similarly, while in reality the first
> item will be treated much differently from the rest.

Interesting.  We could allow an alias on the primary table:
DELETE FROM foo fWHERE

and allow the non-alias version of the table for the join.  Of course,
that doesn't allow "FULL JOIN" and stuff like that.  The FROM ... FROM
looks weird, and there is clearly confusion over the FROM t1, t2.  I
wish there was another option.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [SQL] Efficient DELETE Strategies
Next
From: Bruce Momjian
Date:
Subject: Re: Project scheduling issues (was Re: Per tuple overhead,