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@gmx.net http://funkturm.homeip.net/~peter
