RE: Big 7.1 open items

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: Big 7.1 open items
Дата
Msg-id 000d01bfd729$c24b29c0$2801007e@tpf.co.jp
обсуждение исходный текст
Ответ на Re: Big 7.1 open items  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Big 7.1 open items  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Big 7.1 open items
Следующее
От: Haroldo Stenger
Дата:
Сообщение: Allow nested transactions