RE: Fix for RENAME
От | Hiroshi Inoue |
---|---|
Тема | RE: Fix for RENAME |
Дата | |
Msg-id | 000c01bfd41c$45ff5f40$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: Fix for RENAME (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Can someone comment on this? > It seems to me that we have to reach some consensus in order to get a standard transactional control mechanism to change the allocation of table files. Probably we would have to separate things into 2 parts. 1) Where to allocate tables -- we would need some encapsulation like tablespace. It would be better to be handled differentlyby each storage manager. Note that tablespace is only an encap- sulation and doesn't necessarily mean thatof Oracle. 2) Where tables are allocated -- only specific strorage manager knows the meaing and everything would be treated internally. Under current (file per table) storage manager,#1 isn't necessarily needed for the implementaion of #2 and Ross has already tried it. If we could get some consensus on the future direction of 1)2), we would be able to apply his implementation. Regards. Hiroshi Inoue Inoue@tpf.co.jp > > [ Charset ISO-8859-1 unsupported, converting... ] > > > -----Original Message----- > > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > > > > > > I'm now inclined to introduce a new system relation to store > > > > the physical path name. It could also have table(data)space > > > > information in the (near ?) future. > > > > It seems better to separate it from pg_class because table(data?) > > > > space may change the concept of table allocation. > > > > > > Why not just put it in pg_class? > > > > > > > Not sure,it's only my feeling. > > Comments please,everyone. > > > > We have taken a practical way which doesn't break file per table > > assumption in this thread and it wouldn't so difficult to implement. > > In fact Ross has already tried it. > > > > However there was a discussion about data(table)space for > > months ago and currently a new discussion is there. > > Judging from the previous discussion,I can't expect so much > > that it could get a practical consensus(How many opinions there > > were). We can make a practical step toward future by encapsulating > > the information of table allocation. Separating table alloc info from > > pg_class seems one of the way. > > There may be more essential things for encapsulation. > > > > Comments ? > > > > Regards. > > > > Hiroshi Inoue > > Inoue@tpf.co.jp > > > > > > > -- > 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 > >
В списке pgsql-hackers по дате отправления: