Re: [HACKERS] DROP TABLE inside a transaction block - Mailing list pgsql-hackers

From Lamar Owen
Subject Re: [HACKERS] DROP TABLE inside a transaction block
Date
Msg-id 00030722102200.00601@lorc.wgcr.org
Whole thread Raw
In response to Re: [HACKERS] DROP TABLE inside a transaction block  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] DROP TABLE inside a transaction block  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] DROP TABLE inside a transaction block  (The Hermit Hacker <scrappy@hub.org>)
Re: [HACKERS] DROP TABLE inside a transaction block  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
On Tue, 07 Mar 2000, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> BTW, we are not *that* far from being able to roll back a DROP TABLE.
> >> The only thing that's really needed is for everyone to take a deep
> >> breath and let go of the notion that table files ought to be named
> >> after the tables.  If we named table files after the OIDs of their
> >> tables, then rollback-able DROP or RENAME TABLE would be pretty
> >> straightforward.  If you don't recall why this is, consult the
> >> pghackers archives...
> > The oid will be appended to the base file name.
> If we do it that way, then RENAME TABLE will be kinda complicated...
> not impossible, but is it worth it?

You know, I really hate to disagree with Bruce, but, Tom, you have a point.
IMHO, the benefits of having tables named by OID are going to be numerous --
the schema idea included.  Of course, Bruce's concerns are good concerns as
well. What to do......

Why not do this:

Let the tables be named by OID, and only OID.  Then, for admins' convenience,
put in a flat file that is updated periodically, similarly to pg_pwd being a
flat text dump of pg_shadow.  Since there's going to have to be a system
table mapping table names to OID's anyway, a flat dump of said system table
should be similarly done as pg_pwd.  Call it pg_realnames or something.  Have
it have two columns: OID, and pathname (relative to PGDATA) of table.

This would help admins who might want to restore single tables -- as long as
they have a snapshot of pg_realnames at the same time each table is dumped,
then a restore of pg_realnames into a temp dir, then the actual table can be
restored in by its OID (of course, its OID might have changed in the interim,
but you would simply restore it on top of the OID that that table now maps to).

Besides, the OID for the table itself is not likely to change often.

Bruce, would this allay some of your (entirely valid) concerns?  (I read the
thread about this the first time around, when Vadim said the tbale names
_would_ go to OID's.)

Just my two cents.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] xlog.c.patch for cygwin port.
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] DROP TABLE inside a transaction block