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

On Fri, May 21, 2010 at 11:10 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2010/5/21 Robert Haas <robertmhaas@gmail.com>:
>> On Sat, Apr 24, 2010 at 6:53 PM, Robert Haas <robertmhaas@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