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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers