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

From Christopher Browne
Subject Re: [GENERAL] Creating temp tables inside read only transactions
Date
Msg-id CAFNqd5XZPD4_WOrz6Kj3eAJUQ9MaFrY6T7LJXgcbrNfC9A7biw@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Creating temp tables inside read only transactions  (Michael Nolan <htfoot@gmail.com>)
Responses Re: [GENERAL] Creating temp tables inside read only transactions
List pgsql-hackers
On Mon, Jul 11, 2011 at 12:01 AM, Michael Nolan <htfoot@gmail.com> wrote:
>
>
> On Fri, Jul 8, 2011 at 10:27 PM, Robert Haas <robertmhaas@gmail.com> 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.
>
> Sadly, DBAs don't always have the ability to put all their data in one
> database, even if that is what schemas are for.
>
> The ability to do cross-database (most likely cross-server as well) queries
> would address a lot of real-world problems.

Sure, there's quite a lot of use to that sort of thing.

Once 9.1 is out, with the FDW (Foreign Data Wrapper) concept, it'll
make a lot of sense to add FDW methods for various sorts of access
methods, including accessing other PG instances, cross-server.

We already have a fine mechanism for this; no need to create some
different mechanism out of whole cloth.

Vis-a-vis the attempt to do nested naming, that is "ns1.ns2.table1",
there's a pretty good reason NOT to support that, namely that this
breaks relational handling of tables.  PostgreSQL is a *relational*
database system, hence it's preferable for structures to be
relational, as opposed to hierarchical, which is what any of the
suggested nestings are.

Having to write recursive queries just to look for fully qualified
table names is much more of a bug than it is a feature.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: per-column generic option
Next
From: Florian Weimer
Date:
Subject: Re: reducing the overhead of frequent table locks, v4