Re: [SQL] Efficient DELETE Strategies

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [SQL] Efficient DELETE Strategies
Дата
Msg-id 200206101648.g5AGmG419376@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [SQL] Efficient DELETE Strategies  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: [SQL] Efficient DELETE Strategies
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Project scheduling issues (was Re: Per tuple overhead,