RE: Big 7.1 open items

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> Why is a unique ID better than --- or even different from ---
> >> using the relation's OID?  It seems pointless to me...
> 
> > For example,in the implementation of CLUSTER command,
> > we would need another new file for the target relation in
> > order to put sorted rows but don't we want to change the
> > OID ? It would be needed for table re-construction generally.
> > If I remember correectly,you once proposed OID+version
> > naming for the cases.
> 
> Hmm, so you are thinking that the pg_class row for the table would
> include this uniqueID, 

No,I just include the place where the table is stored(pathname under
current file_per_table storage manager) in the pg_class row because
I don't want to rely on table allocating rule(naming rule for current)
to access existent relation files. This has always been my main point.
Many_tables_in_a_file storage manager wouldn't be able to live without
keeping this kind of infomation.
This information(where it is stored) is diffrent from tablespace(where
to store) information. There was an idea to keep the information into
opaque entry in pg_class which only a specific storage manager
could handle. There was an idea to have a new system table which
keeps the information. and so on...

> and then committing the pg_class update would
> be the atomic action that replaces the old table contents with the
> new?  It does have some attraction now that I think about it.
> 
> But there are other ways we could do the same thing.  If we want to
> have tablespaces, there will need to be a tablespace identifier in
> each pg_class row.  So we could do CLUSTER in the same way as we'd
> move a table from one tablespace to another: create the new files in
> the new tablespace directory, and the commit of the new pg_class row
> with the new tablespace value is the atomic action that makes the new
> files valid and the old files not.
> 
> You will probably say "but I didn't want to move my table to a new
> tablespace just to cluster it!" 

Yes.

> I think we could live with that,
> though.  A tablespace doesn't need to have any existence more concrete
> than a subdirectory, in my vision of the way things would work.  We 
> could do something like making two subdirectories of each place that
> the dbadmin designates as a "tablespace", so that we make two logical
> tablespaces out of what the dbadmin thinks of as one. 

Certainly we could design TABLESPACE(where to store) as above.

> Then we can
> ping-pong between those directories to do things like clustering "in
> place".
>

But maybe we must keep the directory information where the table was 
*ping-ponged* in (e.g.) pg_class. Is such an implementation cleaner or
more extensible than mine(keeping the stored place exactly) ?   
Regards.

Hiroshi Inoue
Inoue@tpf.co.jp