Re: Implementation of global temporary tables?
От | Simon Riggs |
---|---|
Тема | Re: Implementation of global temporary tables? |
Дата | |
Msg-id | CANP8+jJ+V0ihiERMD9PgybYW51Hpk_w=25UjR3VQyT9KkmMADg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Implementation of global temporary tables? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Implementation of global temporary tables?
Re: Implementation of global temporary tables? |
Список | pgsql-hackers |
On 15 July 2015 at 16:28, Andres Freund <andres@anarazel.de> wrote:
There's no complexity in a simple temp table like. We can do this now with triggers.
--
On 2015-07-15 16:24:52 +0100, Simon Riggs wrote:
> It may be possible to do this, though I'm sure there's a wrinkle somewhere.
> But there doesn't seem to be a need to overload the main feature request
> with additional requirements. Doing that is just scope creep that prevents
> us getting features out. Nice, simple patches from newer developers. Later
> tuning and tweaking from more expert community members.
I think that's generally a fair point. But here we're discussing to add
a fair amount of wrinkles with the copy approach. The fact alone that
the oid is different will have some ugly consequences.
Why? We are creating a local temp table LIKE the global temp table. That is already a supported operation. So there is no "different oid".
So we add complexity, just to shift it into different places later? I'm
not sure that's a good idea.
There's no complexity in a simple temp table like. We can do this now with triggers.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: