Re: unnailing shared relations (was Re: global temporary tables)

2010/5/21 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Sat, Apr 24, 2010 at 6:53 PM, Robert Haas <robertmhaas(at)gmail(dot)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 ..

Regards
Pavel Stehule

> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>