Bill Studenmund writes:
> > > Why? Operators are used differently than functions.
> >
> > I don't think so. Operators are a syntacticaly convenience for functions.
> > That's what they always have been and that's what they should stay.
>
> How does what you say disagree with what I said?
>
> Operators certainly have a lot more structure to them than a function call
> does. That's why you give the restriction and join functions, and you hand
> them commutation and negation operators.
These are just hints to the optimizer; they don't affect the invocation
interface.
> So I am a "naive" programmer because I mention intent above?
No.
> So if we have INFORMATION_SCHEMA with the right vies in it, we are fine
> doing whatever we want.
I think some interpretation of the SQL standard can be used to prove that
a new schema should not contain any objects. So you're going to have to
stick to the two predefined schemas to put the system catalogs in. Then
again, other interpretations may be used to prove other things. But to me
the intent of the standard is clear that system catalogs are meant to go
into the defintion schema, and I don't see a reason why this could not be
so.
> > Blech, I meant "you can replace the owner column with the schema column".
>
> That's actually what I thought you said. :-)
>
> I stil think we can't do that, since someone other than the schema owner
> can add a package to a schema. :-) Or at least that's the assumption I'm
> running on; we allow users other than PGUID to create functions (and
> operators and aggregates and types) in the default (whatever it will be
> called) schema, so why shouldn't they be allowed to add packages?
Because SQL says so. All objects in a schema belong to the owner of the
schema. In simple setups you have one schema per user with identical
names. This has well-established use patterns in other SQL RDBMS.
I agree that this might not be what everyone would want, but it seems
extensible. However, I feel we're trying to design too many things at
once. Let's do schemas first the way they're in the SQL standard, and
then we can try to tack on ownership or subschemas or package issues.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
