Re: [HACKERS] DROP TABLE inside a transaction block

> > 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.)

I will fight this to my death. :-)

I have cursed Ingres every time I needed to look at the Ingres data
directory to find out which tables match which files. Even a lookup
file is a pain. Right now, I can do ls -l to see which tables are
taking disk space.

Considering the number of times administrators have to do this, it is a
pain. It is only lazy database internals programmers that would advance
an oid-only file name concept. FYI, Informix SE uses this the
tablename_oid concept in their implementation.

Keeping that flat file in sync with the database will be a royal pain.
Imagine the concurrency problems keeping it up to date.

Guess everyone knows where I stand on this one.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026