Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


            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 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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group