Re: Changing the concept of a DATABASE - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Changing the concept of a DATABASE
Date
Msg-id CA+U5nM+_K0u2ooEom5XtOzRyPhOsMFXqqxPb9AV4zv=KBg6ASA@mail.gmail.com
Whole thread Raw
In response to Re: Changing the concept of a DATABASE  (José Luis Tallón <jltallon@nosys.es>)
Responses Re: Changing the concept of a DATABASE
List pgsql-hackers
On 22 May 2012 12:05, José Luis Tallón <jltallon@nosys.es> wrote:

> IMVHO:  s/database/schema/g does resolve many of the problems that you were
> referring to... and 'dblink' should solve the rest, right?
> Please, feel free to point out what I am (most probably) not considering --
> not experienced enough yet :)

The choice of schema/database is an important one. If you get it
wrong, you are in major difficulty. In many cases schemas would be a
better choice, but not in all cases. So I'm interested in solving the
problems for people who have multiple databases on same server.

dblink is the only solution, but its very poor way to do this when we
have 2 databases on same server.

My thinking is that reaching out to multiple databases is actually
mostly easy, except in a few places where dbid is hardwired into the
backend.

> On the other hand, the separation of databases allows what otherwise would
> only be possible by using multiple instances of the database server (à la
> Oracle, AFAIK ) -- save for resource management, but that is another
> question whatsoever.

Separation of databases is fine. I have no intention to change that,
as long as the user wishes that.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: PostgreSQL - Hans-Jürgen Schönig
Date:
Subject: Re: Getting rid of cheap-startup-cost paths earlier
Next
From: Tatsuo Ishii
Date:
Subject: Re: Patch: add conversion from pg_wchar to multibyte