Re: [HACKERS] DROP TABLE inside a transaction block

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Mike Mascari <mascarm(at)mascari(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Date: 2000-03-08 02:57:36
Message-ID: 00030722102200.00601@lorc.wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 07 Mar 2000, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2000-03-08 03:03:11 Re: [HACKERS] xlog.c.patch for cygwin port.
Previous Message D. Jay Newman 2000-03-08 02:48:28 Re: [HACKERS] xlog.c.patch for cygwin port.