Re: AW: Big 7.1 open items

From: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AW: Big 7.1 open items
Date: 2000-06-28 17:03:18
Message-ID: 20000628120318.A6874@rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 28, 2000 at 02:07:33PM +0200, Zeugswetter Andreas SB wrote:
>
> > AFAIK,schema is independent from user in SQL92.
> > So default_tablespace_per_user doesn't necessarily imply
> > default_tablespace_per_schema.
>
> Well, sombody must be interpreting this wrong, because
> in Informix and Oracle the schema corresponds to the owner
> and they say they conform to ansi in this regard.

To quote from the SQL92 standard for CERATE SCHEMA:

<schema definition> ::=
CREATE SCHEMA <schema name clause>
[ <schema character set specification> ]
[ <schema element>... ]

<schema name clause> ::=
<schema name>
| AUTHORIZATION <schema authorization identifier>
| <schema name> AUTHORIZATION <schema authorization identifier>

1) If <schema name> is not specified, then a <schema name> equal to
<schema authorization identifier> is implicit.

2) If AUTHORIZATION <schema authorization identifier> is not speci-
fied, then

Case:

a) If the <schema definition> is contained in a <module> that
has a <module authorization identifier> specified, then an
<authorization identifier> equal to that <module authoriza-
tion identifier> is implicit for the <schema definition>.

b) Otherwise, an <authorization identifier> equal to the SQL-
session <authorization identifier> is implicit.

So, we see that the SQL92 default fora schema is the session username.

> In both, a user can access other schemas or switch to another
> schema, so in that sense you could say that the schema is
> independent of users.

Not only in a sense, it is in fact.
>
> This will definitely be a problem because of our current nested dot
> interpretation towards functions taking one opaque or _class_type
> argument.

Right. If we're going to support SQL92 dot notation (which I think we
should) we'll either need to lose the function notion completely, or
come up with some really clever hack about applying them in order.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm(at)rice(dot)edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-06-28 17:04:27 Misc. consequences of backend memory management changes
Previous Message Karel Zak 2000-06-28 16:49:47 Re: MySQL has gone GPL