RE: OK, OK, Hiroshi's right: use a seperately-generatedfilename
От | Hiroshi Inoue |
---|---|
Тема | RE: OK, OK, Hiroshi's right: use a seperately-generatedfilename |
Дата | |
Msg-id | 001201bfd9aa$2f1c1320$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: OK, OK, Hiroshi's right: use a seperately-generated filename (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
> -----Original Message----- > From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On > Behalf Of Peter Eisentraut > > Tom Lane writes: > > > I don't think it's a good idea to have to consult pg_tablespace to find > > out where a table actually is --- I think the pathname (or smgr access > > token as Ross would call it ;-)) ought to be determinable from just the > > pg_class entry. > > That's why I suggested the table space oid. That would be readily > available from pg_class. > It seems to me that the following 1)2) has always been mixed up. IMHO,they should be distinguished clearly. 1) Where the table is stored Currently PostgreSQL relies on relname -> filename mapping rule to access *existent* relationsand doesn't have this information in its database. Our(Tom,Ross,me) proposal is to keep the information(token)in pg_class and provide a standard transactional control mechanism for the change of table file allocation.By doing it we would be able to be free from table allocation(naming) rule. Isn't it a kind of thing why wehaven't had it from the first ? 2) Where to store the table Yes,TABLE(DATA)SPACE should encapsulate this concept. I want the decision about 1) first. Ross has already tried it without 2). Comments ? As for 2) every one seems to have each opinion and the discussion has always been divergent. Please don't discard 1) together. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: