Re: Big 7.1 open items

Tom Lane wrote:
> "Oliver Elphick" <olly@lfix.co.uk> writes:
> > I suggest that DROP TABLE in a transaction should not be allowed.
>
> I had actually made it do that for a short time early this year,
> and was shouted down.  On reflection I have to agree; it's too useful
> to be able to do
>
>    begin;
>    drop table foo;
>    create table foo(new schema);
>    ...
>    end;
>
> You do indeed lose big if you suffer an error partway through, but
> the answer to that is to fix our file naming conventions so that we
> can support rollback of drop table.
   Belongs  IMHO  to  the  discussion  to  keep separate what is   separate  (having  indices/toast-relations/etc.  in
separate  directories and whatnot).
 
   I've   never   been   really   happy  with  the  file  naming   conventions. The need of a filesystem entry to have
the same   name of the DB object that is associated with it isn't right.   I know, some people love to be able to
easily identify  the   files with ls(1). OTOH what is that good for?
 
   Well,  someone  can  easily see how big the disk footprint of   his data is.  Whow - what an info. Anything else?
   Why not changing the naming to be something like this:
       <dbroot>/catalog_tables/pg_...       <dbroot>/catalog_index/pg_...       <dbroot>/user_tables/oid_...
<dbroot>/user_index/oid_...      <dbroot>/temp_tables/oid_...       <dbroot>/temp_index/oid_...
<dbroot>/toast_tables/oid_...      <dbroot>/toast_index/oid_...       <dbroot>/whatnot_???/...
 
   This way, it  would  be  much  easier  to  separate  all  the   different  object types to different physical media.
Wewould   loose some  transparency,  but  I've  allways  wondered  what   people  USE  that  for  (except  for  just
wanna know). For   convinience we could implement another  little  utility  that   tells the object size like
 
       DESCRIBE TABLE/VIEW/whatnot <object-name>
   that returns the physical location and storage details of the   object. And psql could use it to print this  info
additional  on  the  \d commands. Would give unprivileged users access to   this info, so be it, it's not a security
issueIMHO.
 
   The subdirectory an object goes into has to be controlled  by   the relkind. So we need to tidy up that a little
too.I think   it's worth it.
 
   The objects  storage  location  (the  bare  file)  now  would   contain  the  OID.  So  we  avoid  naming  conflicts
fortemp   tables, naming conflicts during DROP/CREATE in a  transaction   and all the like.
 
   Comments?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #