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

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: [GENERAL] Creating temp tables inside read only transactions
Дата
Msg-id CAFNqd5XZPD4_WOrz6Kj3eAJUQ9MaFrY6T7LJXgcbrNfC9A7biw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Creating temp tables inside read only transactions  (Michael Nolan <htfoot@gmail.com>)
Ответы Re: [GENERAL] Creating temp tables inside read only transactions
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: per-column generic option
Следующее
От: Florian Weimer
Дата:
Сообщение: Re: reducing the overhead of frequent table locks, v4