Re: AW: Big 7.1 open items

Поиск
Список
Период
Сортировка
От Ross J. Reedstrom
Тема Re: AW: Big 7.1 open items
Дата
Msg-id 20000628120318.A6874@rice.edu
обсуждение исходный текст
Ответ на AW: AW: Big 7.1 open items  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Список 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>
isimplicit.
 
        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>
isimplicit.
 

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@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Karel Zak
Дата:
Сообщение: Re: MySQL has gone GPL
Следующее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: AW: Big 7.1 open items