RE: Big 7.1 open items - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: Big 7.1 open items
Date
Msg-id 000d01bfd729$c24b29c0$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: Big 7.1 open items  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Big 7.1 open items
List pgsql-hackers
> -----Original Message-----
> From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
> Behalf Of Tom Lane
> 
> "Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> > On Thu, Jun 15, 2000 at 03:11:52AM -0400, Tom Lane wrote:
> >> "Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> >>>> Any strong objections to the mixed relname_oid solution?
> >> 
> >> Yes!
> 
> > 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.
> 
> Yeah, I've seen tons of discussion of how if we do this, that, and
> the other thing, and be prepared to fix up some other things in case
> of crash recovery, we can make it work with filename == relname + OID
> (where relname tracks logical name, at least at some remove).
>

I've seen little discussion of how to avoid the use of naming rule.
I've proposed many times that we should keep the information
where the table is stored in our database itself. I've never seen
clear objections to it. So I could understand my proposal is OK ? 
Isn't it much more important than naming rule ?  Under the
mechanism,we could easily replace bad naming rule.
And I believe that Ross's work is mostly around the mechanism
not naming rule. 

Now I like neither relname nor oid because it's not sufficient 
for my purpose. 
Regards.

Hiroshi Inoue
Inoue@tpf.co.jp


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Big 7.1 open items
Next
From: Haroldo Stenger
Date:
Subject: Allow nested transactions