From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
Cc: | "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | RE: OK, OK, Hiroshi's right: use a seperately-generatedfilename |
Date: | 2000-06-19 04:52:34 |
Message-ID: | 001201bfd9aa$2f1c1320$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)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* relations and 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 we haven'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(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-06-19 04:53:49 | Re: Big 7.1 open items |
Previous Message | Tom Lane | 2000-06-19 04:52:28 | Re: int24_ops and int42_ops are bogus |