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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unnailing shared relations (was Re: global temporary tables)
Date: 2010-05-24 20:23:37
Message-ID: 1274732269-sup-6739@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Hunsberger 2010-05-24 20:23:38 Re: Hiding data in postgresql
Previous Message Hector Beyers 2010-05-24 20:18:51 Re: Hiding data in postgresql