On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010: > >> Actually, there's another way we could do this. Instead of creating >> pg_shared_class and pg_shared_attribute and moving all of the catalog >> entries for the shared relations into those tables, we could consider >> leaving the catalog entries in the unshared copies of pg_class, >> pg_attribute, etc. and DUPLICATING them in a shared catalog which >> would only be used prior to selecting a database. Once we selected a >> database we'd switch to using the database-specific pg_class et al. >> Obviously that's a little grotty but it might (?) be easier, and >> possibly a step along the way. > > Uh, how does this work when you change the entries for shared relations > in a database-specific pg_class? Keeping everything in sync seems hard, > if not impossible.
Well, I might be missing something here, but pg_class already IS database-specific. If you change anything very significant about a shared rel in one copy of pg_class today, you're toast, IIUC. This proposal doesn't make that any better, but I don't think it makes it any worse either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
