Re: schema support, was Package support for Postgres

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.

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

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

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

> Hmmm... We probably also need a command to create operator classes, and
> the tables it touches would need a schema column too, and accesses will
> need to be schema savy.
>
> Well, that's a lot for now. Thoughts?

That "lot" was sort of the problem with tackling this until now. ;-)

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