Zeugswetter Andreas SB wrote:
> > > > > The symlinks wouldn't do any good for what Bruce had in
> > > > > mind anyway (IIRC, he wanted to get useful per-database
> > > > > numbers from "du").
> > > >
> > > > Our database design seems to be in the opposite direction
> > > > if it is restricted for the convenience of command calls.
> > >
> > > Well, I don't see any reason not to use tablespace/database
> > > rather than just tablespace. Seems having fewer files in
> > each directory
> >
> > Once again - ability to use different tablespaces (disks) for
> > tables/indices
> > in the same schema. Schemas must not dictate where to store objects <-
> > bad design.
>
> Can we agree, that the schema is below the database hierarchy, and thus
> is something different than a database ?
I don't think we have a common understanding for PG's *database*
(created by createdb). Every one seems to have his own *database*.
According to your another posting,your *database* hierarchy is instance -> database -> schema -> object
like Oracle.
However SQL92 seems to have another hierarchy: cluster -> catalog -> schema -> object
and dot notation catalog.schema.object could be used.
I couldn't find clear correspondense between PG's *database*
and above hierarchy because we have no dot notation for
objects currently.
>
> A table under another schema will simply get another oid, and thus no
> collision.
> But I agree that schema should not dictate storage location,
> but the schema might imply a default storage location like in Oracle
> (default tablespaces for a user).
AFAIK,schema is independent from user in SQL92.
So default_tablespace_per_user doesn't necessarily imply
default_tablespace_per_schema.
Regards.
Hiroshi Inoue