RE: Big 7.1 open items

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Subject: RE: Big 7.1 open items
Date: 2000-06-16 00:28:14
Message-ID: 000d01bfd729$c24b29c0$2801007e@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)org]On
> Behalf Of Tom Lane
>
> "Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> > 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!
>
> > 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(at)tpf(dot)co(dot)jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haroldo Stenger 2000-06-16 01:26:28 Allow nested transactions
Previous Message Isaac Wilcox 2000-06-16 00:10:02 Re: PostgreSQL aggregate function documentation

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2000-06-16 01:57:27 Re: Big 7.1 open items
Previous Message Tom Lane 2000-06-15 23:57:05 Re: Big 7.1 open items