> -----Original Message-----
> From: Peter Eisentraut [mailto:e99re41@DoCS.UU.SE]
> 
> > My opinion
> >    3) database and tablespace are relatively irrelevant.
> >        I assume PostgreSQL's database would correspond 
> >        to the concept of SCHEMA.
> 
> A database corresponds to a catalog and a schema corresponds to nothing
> yet.
>

Oh I see your point. However I've thought that current PostgreSQL's
database is an imcomplete SCHEMA and still feel so in reality.
Catalog per database has been nothing but needless for me from
the first.

Regards.  

Hiroshi Inoue
Inoue@tpf.co.jp

Thu, 22 Jun 2000 18:07:18 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: Big 7.1 open items 
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> A database corresponds to a catalog and a schema corresponds to nothing
>> yet.

> Oh I see your point. However I've thought that current PostgreSQL's
> database is an imcomplete SCHEMA and still feel so in reality.
> Catalog per database has been nothing but needless for me from
> the first.

It may be needless for you, but not for everybody ;-).

In my mind the point of the "database" concept is to provide a domain
within which custom datatypes and functions are available.  Schemas
will control the visibility of tables, but SQL92 hasn't thought about
controlling visibility of datatypes or functions.  So I think we will
still want "database" = "span of applicability of system catalogs"
and multiple databases allowed per installation, even though there may
be schemas subdividing the database(s).

			regards, tom lane

Thu, 22 Jun 2000 11:22:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Big 7.1 open items 
Tom Lane writes:

> In my mind the point of the "database" concept is to provide a domain
> within which custom datatypes and functions are available.

Quoth SQL99:

"A user-defined type is a schema object"

"An SQL-invoked routine is an element of an SQL-schema"

I have yet to see anything in SQL that's a per-catalog object. Some things
are global, like users, but everything else is per-schema.

The way I see it is that schemas are required to be a logical hierarchy,
whereas implementations may see catalogs as a physical division (as indeed
this implementation does).

> So I think we will still want "database" = "span of applicability of
> system catalogs"

Yes, because the system catalogs would live in a schema of their own.


-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Fri, 23 Jun 2000 00:36:28 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Big 7.1 open items 
> -----Original Message-----
> From: Peter Eisentraut
>
> Tom Lane writes:
>
> > In my mind the point of the "database" concept is to provide a domain
> > within which custom datatypes and functions are available.
>

AFAIK few users understand it and many users have wondered
why we couldn't issue cross "database" queries.

> Quoth SQL99:
>
> "A user-defined type is a schema object"
>
> "An SQL-invoked routine is an element of an SQL-schema"
>
> I have yet to see anything in SQL that's a per-catalog object. Some things
> are global, like users, but everything else is per-schema.
>

So why is system catalog needed per "database" ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp


Fri, 23 Jun 2000 08:35:12 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: Big 7.1 open items 