On Fri, May 21, 2010 at 11:10 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2010/5/21 Robert Haas <robertmh...@gmail.com>: >> On Sat, Apr 24, 2010 at 6:53 PM, Robert Haas <robertmh...@gmail.com> >> wrote (in reply to Tom Lane): >>> If we create, e.g. pg_shared_class and >>> pg_shared_attribute, then we can un-nail the catalogs you just nailed >>> to make the authentication process able to work without selecting a >>> database. >> >> 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. >> > > I did it - just on syscache level - but there are problem with > refresh. I though about some special pseudo persistent data pages > attached to possible any table with temp data. Then you don't need > modify any on higher level, you don't need new catalog entries, etc ..
I don't think we're talking about the same thing. -- 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