Re: schema support, was Package support for Postgres

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.

> Conceptually the main determiner of what function you want is the name, at
> least as far as from what I can tell from talking with all the programmers
> I know. Yes, we make sure the types match (are part of the primary key),
> but the name is the main concept. Operators, however, are more
> intent-based. The '+' operator means I want these two things added
> together. I don't care so much what types are involved, I want adding to
> happen. That's a difference of intent. And that's the reason that I think
> different namespacing rules make sense.

Naive developers all program by "intent". If I invoke a + operator then I
expect it to add. If I call a sqrt() function then I expect it to
calculate the square root. If I execute an INSERT statement then I would
prefer that I did not delete anything. Designing systems to work by
"intent" can be construed as an aspect of "user-friendliness".

But the more knowledgeable programmer is mildly aware of what's going on
behind the scenes: Both "+" and "sqrt" are just names for function code
that may or may not do what you think they do. So this applies to both
functions and operators.

> Part of it is that I only expect a package to add operators for types it
> introduced.

This is an arbitrary restriction that you might find reasonable, but other
developers might not.

> Another take on that is that I expect the main user of (direct) function
> calls calling package functions will be other functions in that package,
> while the main users of operators will be places which have used a type
> from said package.

See above.

> To add something like an absolute path would totally break the whole
> motivation for packages.

Yes. If we add something like subschemas then something more
sophisticated than a Unix-style path would have to be engineered.

> > The built-in schemas is called DEFINITION_SCHEMA.
>
> Why is it different from the "DEFAULT" you get when you log into a
> database which doesn't have a schema whose name matches your username?

Because SQL says so.

> > > The only other part (which is no small one) is to add namespacing to the
> > > rest of the backend. I expect that will mean adding a schema column to
> > > pg_class, pg_type, and pg_operator.
> >
> > Yup. But you can replace the owner package with the schema column,
> > because the owner property will be transferred to the schema.
>
> Not necessarily. A user other than the one who owns the schema can add a
> package to it. It's the same thing as why we keep track of who added a
> function. :-)

Blech, I meant "you can replace the owner column with the schema column".

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter