RE: OK, OK, Hiroshi's right: use a seperately-generatedfilename - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: OK, OK, Hiroshi's right: use a seperately-generatedfilename
Date
Msg-id 001201bfd9aa$2f1c1320$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: OK, OK, Hiroshi's right: use a seperately-generated filename  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Don Baccus
Date:
Subject: Re: Big 7.1 open items
Next
From: Tom Lane
Date:
Subject: Re: int24_ops and int42_ops are bogus