Re: schema support, was Package support for Postgres
От | Peter Eisentraut |
---|---|
Тема | Re: schema support, was Package support for Postgres |
Дата | |
Msg-id | Pine.LNX.4.30.0110202251510.827-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: schema support, was Package support for Postgres (Bill Studenmund <wrstuden@netbsd.org>) |
Ответы |
Re: schema support, was Package support for Postgres
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: