
> "Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> > Any strong objections to the mixed relname_oid solution?
> 
> Yes!
> 
> You cannot make it work reliably unless the relname part is 
> the original
> relname and does not track ALTER TABLE RENAME.

It does, or should at least. Only problem case is where db crashes during
alter or commit/rollback. This could be fixed by first open that fails to
find the file
or vacuum, or some other utility.

>  IMHO having 
> an obsolete
> relname in the filename is worse than not having the relname at all;
> it's a recipe for confusion, it means you still need admin 
> tools to tell
> which end is really up, and what's worst is you might think you don't.
> 
> Furthermore it requires an additional column in pg_class to keep track
> of the original relname, which is a waste of space and effort.

it does not.

> Finally, one of the reasons I want to go to filenames based 
> only on OID
> is that that'll make life easier for mdblindwrt.  Original 
> relname + OID
> doesn't help, in fact it makes life harder (more shmem space needed to
> keep track of the filename for each buffer).

I do not see this. filename is constructed from relname+oid.
if not found, do directory scan for *_<OID>.dat, if found --> rename.

Andreas

Thu, 15 Jun 2000 10:26:12 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: Big 7.1 open items 
> > Finally, one of the reasons I want to go to filenames based 
> > only on OID
> > is that that'll make life easier for mdblindwrt.  Original 
> > relname + OID
> > doesn't help, in fact it makes life harder (more shmem space needed to
> > keep track of the filename for each buffer).
> 
> I do not see this. filename is constructed from relname+oid.
> if not found, do directory scan for *_<OID>.dat, if found --> rename.

That is kind if nifty.

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

Thu, 15 Jun 2000 09:49:46 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: AW: Big 7.1 open items