On 22/05/12 13:24, Simon Riggs wrote:
> 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.
Ok. Understood.
Thank you for the clarification
> 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.
The only drawback I see is that it might weaken the separation.
Even though arguably a kludge, dblink could have a "shortcut" added,
whereby connections to another database within the same cluster would be
serviced directly within the backend, as opossed to opening a new db
connection. This is effectively a fastpath within dblink, which
optimizes a relatively common case while at the same time not loosing
generality.
>> 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.
Perfect.
Thanks,
Jose Luis Tallon
