Re: [GENERAL] Creating temp tables inside read only transactions

Поиск
Список
Период
Сортировка
От Darren Duncan
Тема Re: [GENERAL] Creating temp tables inside read only transactions
Дата
Msg-id 4E17D367.3050308@darrenduncan.net
обсуждение исходный текст
Ответ на Re: [GENERAL] Creating temp tables inside read only transactions  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [GENERAL] Creating temp tables inside read only transactions  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: libpq SSL with non-blocking sockets
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Creating temp tables inside read only transactions