Re: [SQL] More efficient DELETE ... ?
От | Bruce Momjian |
---|---|
Тема | Re: [SQL] More efficient DELETE ... ? |
Дата | |
Msg-id | 200001221937.OAA25487@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [SQL] More efficient DELETE ... ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [SQL] More efficient DELETE ... ?
|
Список | pgsql-sql |
> The Hermit Hacker <scrappy@hub.org> writes: > > This looks painful ... > > > DELETE FROM webhit_referer_raw > > WHERE oid IN ( SELECT w.oid > > FROM webhit_referer_raw w, referrer_data r > > WHERE stat_date < 'Jan 17 2000 15:05:00' > > AND w.referrer_url = r.referrer ); > > I believe you can do > > DELETE FROM webhit_referer_raw > WHERE referrer_url = referrer_data.referrer > AND referrer_data.stat_date < 'Jan 17 2000 15:05:00'; > > (I assume stat_date is in referrer_data, otherwise this'd be easy.) > > This is an example where Postgres' willingness to create implicit FROM > clause entries is a win ... AFAIK you couldn't do it in standard SQL, > since for some reason DELETE doesn't take a FROM clause. Good point. I had forgotten all about that. Should I cover that in my book? What about the NOTICE we were going to add when this happens. You will see a WARN_FROM define in parser/*.c. I had to disable the message because the regression tests were failing. They have to be regenerated after I do this, but I can't do that here. Do people still want the message? Can someone regenerate the regression output after I am done? In fact, someone can just remove the #ifdef WARN_FROM defines around the code and regenerate the regression tests and all will stay in sync. -- Bruce Momjian | http://www.op.net/~candle 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-sql по дате отправления: