Re: schema support, was Package support for Postgres

On Sun, 21 Oct 2001, Peter Eisentraut wrote:

> Bill Studenmund writes:
>
> > The big one for now is how should you log into one schema or another?
> > psql database.schema ?
>
> Each user has a default schema, which is by default the schema with the
> same name as the user name, or if no such schema exists, it's the DEFAULT
> schema (which I believe is what Oracle calls it). Then there should be
> something like set schema path. I don't think schemas should be a
> connection parameter. -- That would be my ideas anyway.

I can see advantages for both; if you just connect to a database that has
schemas, you get a schema with your name if it's there, and a default
otherwise. But I can see definite advantages to being able to specify.

> > Whenever you look up a function or aggregate, you give the oid of the
> > package to look in in addition to the name (and types). Having the package
> > id in the index provides the namespacing.
> >
> > Whenever you look up a type or operator, you don't have to give a package
> > id.
>
> While I understand that package.+ is silly, anything that make operators
> and functions work fundamentally differently is suspicious. A common
> search mechanism that works for everything in packages (or subschemas,
> which I'd prefer) would/should/could allow you to do without those
> prefixes.

Why? Operators are used differently than functions. That strikes me as a
good reason to namespace them differently.

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.

Part of it is that I only expect a package to add operators for types it
introduced. So to be considering them, you had to have done something that
ties in the type in the package. Like you had to make a column in a table
using it.

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. Like queries pulling things out of tables using that
type. So the function namespacing is a concenience/tool primarily for the
package developer, while the operator and type namespacing is more a
convenience for the end application developer.

Also, you seem to be wanting a path-search ability that is something like
the PATH environment variable. This pathing is fundamentally different; to
use unix terms, it is ".:..". The fundamental difference is that there are
no "absolute" paths. The searching is totally location (of routine)
dependant.

To add something like an absolute path would totally break the whole
motivation for packages. The idea is to give a developer an area overwhich
s/he has total name control, but if s/he needs built-in routines, s/he
doesn't need to say "standard." to get at them.

If we allow something like "absolute paths" in the package namespacing,
then we totally destroy that. Because a package developer can't be sure
what pathing is going on, s/he really has no clue what packages will get
found in what order. So then you have to be explicit in the name of all
the functions you use (otherwise if a user essentially puts something
other than "." at the head of the path, then you don't get routines in
your own package), or run the risk of getting all sorts of run-time
errors. A feature designed to make writing packages easier now makes them
harder. That strikes me as a step backwards.

> > There is a built-in schema, "master". It will have a fixed oid, probalby 9
> > or 11.
>
> 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?

> > 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. :-)

Take care,

Bill