Andres Freund <and...@anarazel.de> writes:
> 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.
With all due respect, there are features that are beyond the abilities of
some "newer developers", and reducing the scope isn't a good way to fix
that. It just leaves a bigger mess to be cleaned up later.
I think Andres' idea of a per-backend filenode mapping table might work.
The existing relfilenode mapper solves a somewhat related problem, namely
how do you replace the filenode for shared system catalogs whose pg_class
entries can't be changed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
