| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Zhaomo Yang <zhy001(at)cs(dot)ucsd(dot)edu>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Implementation of global temporary tables? |
| Date: | 2015-07-15 15:28:35 |
| Message-ID: | 20150715152835.GK5520@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
So we add complexity, just to shift it into different places later? I'm
not sure that's a good idea.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2015-07-15 15:36:12 | Re: Implementation of global temporary tables? |
| Previous Message | Simon Riggs | 2015-07-15 15:24:52 | Re: Implementation of global temporary tables? |