Re: [GENERAL] Creating temp tables inside read only transactions - Mailing list pgsql-hackers

From Darren Duncan
Subject Re: [GENERAL] Creating temp tables inside read only transactions
Date
Msg-id 4E17D367.3050308@darrenduncan.net
Whole thread Raw
In response to Re: [GENERAL] Creating temp tables inside read only transactions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [GENERAL] Creating temp tables inside read only transactions  (Jeff Davis <pgsql@j-davis.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: libpq SSL with non-blocking sockets
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Creating temp tables inside read only transactions