Re: Big 7.1 open items

On Thu, Jun 15, 2000 at 03:11:52AM -0400, Tom Lane wrote:
> "Ross J. Reedstrom" <reedstrm(at)rice(dot)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. 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.

The plan here was to let VACUUM handle renaming the file, since it
will already have all the necessary locks. This shortens the window
of confusion. ALTER TABLE RENAME doesn't happen that often, really -
the relname is there just for human consumption, then.

>
> Furthermore it requires an additional column in pg_class to keep track
> of the original relname, which is a waste of space and effort.
>

I actually started down this path thinking about implementing SCHEMA,
since tables in the same DB but in different schema can have the same
relname, I figured I needed to change that. We'll need something in
pg_class to keep track of what schema a relation is in, instead.

> It also creates a portability risk, or at least fails to remove one,
> since you are critically dependent on the assumption that the OS
> supports long filenames --- on a filesystem that truncates names to less
> than about 45 characters you're in very deep trouble. An OID-only
> approach still works on traditional 14-char-filename Unix filesystems
> (it'd mostly even work on DOS 8+3, though I doubt we care about that).

Actually, no. Since I store the filename in a name attribute, I used this
nifty function somebody wrote, makeObjectName, to trim the relname part,
but leave the oid. (Yes, I know it's yours ;-)

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

Can you explain in more detail how this helps? Not by letting the bufmgr
know that oid == filename, I hope. We need to improving the abstraction
of the smgr, not add another violation. Ah, sorry, mdblindwrt _is_
in the smgr.

Hmm, grovelling through that code, I see how it could be simpler if reloid
== filename. Heck, we even get to save shmem in the buffdesc.blind part,
since we only need the dbname in there, now.

Hmm, I see I missed the relpath_blind() in my patch - oops. (relpath()
is always called with RelationGetPhysicalRelationName(), and that's
where I was putting in the relphysname)

Hmm, what's all this with functions in catalog.c that are only called by
smgr/md.c? seems to me that anything having to do with physical storage
(like the path!) belongs in the smgr abstraction.

>
> Can we *PLEASE JUST LET GO* of this bad idea? No relname in the
> filename. Period.
>

Gee, so dogmatic. No one besides Bruce and Hiroshi discussed this _at
all_ when I first put up patches two month ago. O.K., I'll do the oids
only version (and fix up relpath_blind)

Ross

--
Ross J. Reedstrom, Ph.D., <reedstrm(at)rice(dot)edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005