Re: Big 7.1 open items

Tom Lane wrote:
> "Oliver Elphick" <olly(at)lfix(dot)co(dot)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. We would
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 issue IMHO.

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 for temp
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(at)Yahoo(dot)com #