From: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RFD: schemas and different kinds of Postgres objects |
Date: | 2002-01-23 00:18:13 |
Message-ID: | 20020123001812.GB7932@rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 22, 2002 at 06:31:08PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Moreover, I figure if we do it that
> > way, the whole schema implementation reduces itself mostly to parser work,
> > no complicated system catalog changes, no complex overhaul of the
> > privilege system -- at least initially.
>
> Why are you guys so eager to save me work? I'm not in the least
> interested in implementing a "schema" feature that can only handle
> the entry-level user == schema case. Therefore, just relabeling the
> owner column as schema isn't an interesting option.
>
> I really don't see what's wrong with building a namespace mechanism
> that is orthogonal to ownership and then using that to implement what
> SQL92 wants. I think this will be cleaner, simpler, and more flexible
> than trying to equate ownership with namespace.
>
I'm with Tom on this: the extended Schema capability he's described
combines the best of both authentication mechanisms, IMHO. It give
us namespace separation ala the SQL standard, and individual object
ownership, like unix FS semantics. Only having ownership on the
'containers' strikes me as limiting, even if that is how the standard
describes it.
Ross
From | Date | Subject | |
---|---|---|---|
Next Message | Ross J. Reedstrom | 2002-01-23 00:46:08 | Re: Cross posting |
Previous Message | Tom Lane | 2002-01-23 00:11:35 | Re: Cross posting |