Re: INS/UPD/DEL RETURNING for 8.2
От | Jonah H. Harris |
---|---|
Тема | Re: INS/UPD/DEL RETURNING for 8.2 |
Дата | |
Msg-id | 36e682920603021747l3fea5d9ctf1012b80b6a4bae1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INS/UPD/DEL RETURNING for 8.2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
On 3/2/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I was thinking along the same lines. This is Omar's patch updated to 8.2 but as I get to looking through it, there are a couple things that could be cleaned up. I paced around a bit today trying to theorize how this could be done without a lot of changes and retaining the speed increase gained by not performing two separate operations.
I'm definitely open to looking into it. Any suggestions are always welcome.
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324
This might tie into something that was bothering me about Jonah's
first-cut patch, which was that he was introducing special cases into
places where it didn't seem real appropriate (like printtup.c). I
wonder if we should rejigger the representation of Query so that a
FOO-RETURNING command actually *is* a SELECT in some sense, so that
there's no need for special cases.
I was thinking along the same lines. This is Omar's patch updated to 8.2 but as I get to looking through it, there are a couple things that could be cleaned up. I paced around a bit today trying to theorize how this could be done without a lot of changes and retaining the speed increase gained by not performing two separate operations.
I'm a bit fuzzy about how this would work exactly --- you still need to
keep track of two targetlists it seems --- but it's worth thinking
about. I've had a bee in my bonnet for literally years about the fact
that INSERT/SELECT really needs two levels of targetlist, as does UNION.
Maybe if we thought a little bit larger we could clean up all of that
messiness at one stroke.
I'm definitely open to looking into it. Any suggestions are always welcome.
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324
В списке pgsql-patches по дате отправления: