Re: INS/UPD/DEL RETURNING for 8.2
От | Bruce Momjian |
---|---|
Тема | Re: INS/UPD/DEL RETURNING for 8.2 |
Дата | |
Msg-id | 200604270245.k3R2jcn00847@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: INS/UPD/DEL RETURNING for 8.2 ("Jonah H. Harris" <jonah.harris@gmail.com>) |
Список | pgsql-patches |
Jonah, where are we on this patch? Do you have a version ready for review? --------------------------------------------------------------------------- Jonah H. Harris wrote: > On 3/2/06, Jonah H. Harris <jonah.harris@gmail.com> wrote: > > > > On 3/2/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > > "Jonah H. Harris" <jonah.harris@gmail.com> writes: > > > > INSERT/UPDATE/DELETE seem to work fine in normal operation but there > > > is an > > > > error with DELETE RETURNING when used through PL/pgSQL. > > > > > > Probably other places too. I don't see any provision here for ensuring > > > that the variables used in the RETURNING list are actually computed by > > > the plan. This would be masked in the INSERT and non-join UPDATE cases > > > by the fact that the plan has to compute all columns of the target table > > > anyway ... but in a DELETE it'd be an issue. > > > > > > I think set-returning functions in the RETURNING list might give you > > > some fits too ... > > > > > > Yeah, I got to looking into the special tuple handling code in execUtils > > for retrieving the old (deleted) tuple and there's something definitely > > getting lost along the way in some cases. > > > > I've been stewing on this and haven't yet come up with anything. Have you > any thoughts on how we can accomplish this better? > > > -- > Jonah H. Harris, Database Internals Architect > EnterpriseDB Corporation > 732.331.1324 -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: