Robert Haas wrote:
But if that's what you want, just don't put your data in different
databases in the first place. That's what schemas are for.
If for some reason we needed to have tables that happened to be called
x.y.z and a.b.c accessible from a single SQL session, we could allow
that much more simply by allowing schemas to be nested. Then we could
allow arbitrary numbers of levels, not just three. The whole point of
having databases and schemas as separate objects is that they do
different things: schemas are just containers for names, allowing
common access to data, and databases are completely separate entities,
allowing privilege separation for (say) a multi-tenant hosting
environment. We're not going to throw out the latter concept just so
people can use two dots in their table names instead of one.
I agree with what you're saying in general and that schema namespaces should be
nestable to arbitrary levels. One dot or two isn't an issue I have.
Dividing based on databases or on schemas is a big and important distinction.
I see that the semantic purpose of using multiple databases is to allow things
to be completely independent and self-defined, where one can understand the
meaning of any one database in isolation. So one can take each of the 2
databases and walk off with them in opposite directions, and each can still be
used and understood.
Whereas, schemas are namespaces for organizing entities within a single database
where any of those entities may be interdependent, such as defining a data type
in one schema and using it as the declared type with a routine or table or
constraint in another.
But just because you use multiple databases in order for them to be independent,
sometimes one still wants to use them together, and an abstraction loosely like
federating is useful here.
I think you should make more of an effort to understand how the system
works now, and why, before proposing radical redesigns.
Well yes, of course. But that will take time and I think I already understand
enough about it to make some useful contributions in the meantime. How much or
what I already know may not always come across well. If this bothers people
then I can make more of an effort to reduce my input until I have more solid
things to back them up.
-- Darren Duncan
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
