Re: referring to a different database from a trigger

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: pw <p(dot)willis(at)telus(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: referring to a different database from a trigger
Date: 2008-11-21 23:45:42
Message-ID: dcc563d10811211545i5faaa26an6d35deace98c4c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Nov 21, 2008 at 4:43 PM, pw <p(dot)willis(at)telus(dot)net> wrote:
> Scott Marlowe wrote:
>>
>> On Fri, Nov 21, 2008 at 3:31 PM, ries van Twisk <pg(at)rvt(dot)dds(dot)nl> wrote:
>>
>> Note that there are no built in transactional symantics in such
>> situations. You got to roll your own. And they may not work.
>>
>
>
> Yeah, that was what I was hoping for.
>
> ie:(query between databases)
>
> SELECT db_one.table_one.column_name_one, db_two.table_oranges.column_fluff
> FROM db_one.table_one, db_two.table_oranges WHERE
> db_one.table_one.some_id=db_two.table_oranges.raisin_id;
>
> <sigh> Oh well!, I'll just do it in code I guess....
>
> I can see where the difficulties lay in this.
> It would require a pipeline between the two databases
> allowing one of them to share tables, difficult if there
> are common oids pointing to completely different objects.
> Oids/schemas would need to be aliased in some way to give them
> pseudo-representation in the destination database.

can you use database schemas to accomplish the same thing? i.e. put
it all in one database and use schemas to partition them? or do you
have other requirements that make that a no go?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Zagato 2008-11-22 01:39:52 Interval Format
Previous Message pw 2008-11-21 23:43:07 Re: referring to a different database from a trigger