Re: question about selecting across multiple dbs

Hello,
I see that there is an item "Queries across databases or servers (two-phase commit)" on the todo list's urgent header. I have tried asking this question on the other lists and have not yet gotten a suitable answer to this question...When is this functionality expected to be available in PostgreSQL? I as well as many others want to be able to run queries such as

SELECT a.field_a, b.field_b FROM user:pwd(at)host(dot)database(dot)schema(dot)table_a AS a NATURAL JOIN local_table AS b;

Thanks in advance,

-Joe

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Mon, 2004-03-08 at 11:57, Joe Maldonado wrote:
> Hello,
> I see that there is an item "Queries across databases or servers (two-phase commit)" on the todo list's urgent header. I have tried asking this question on the other lists and have not yet gotten a suitable answer to this question...When is this functionality expected to be available in PostgreSQL? I as well as many others want to be able to run queries such as
>
> SELECT a.field_a, b.field_b FROM user:pwd(at)host(dot)database(dot)schema(dot)table_a AS a NATURAL JOIN local_table AS b;

Cross database selects can be accomplished using contrib/dblink.

It will be some time before cross database writes or locks will be
possible.

On Mon, 08 Mar 2004 12:18:22 -0500, Rod Taylor <pg(at)rbt(dot)ca> wrote:

> On Mon, 2004-03-08 at 11:57, Joe Maldonado wrote:
>> Hello,
>> I see that there is an item "Queries across databases or servers (two-phase commit)" on the todo list's urgent header. I have tried asking this question on the other lists and have not yet gotten a suitable answer to this question...When is this functionality expected to be available in PostgreSQL? I as well as many others want to be able to run queries such as
>>
>> SELECT a.field_a, b.field_b FROM user:pwd(at)host(dot)database(dot)schema(dot)table_a AS a NATURAL JOIN local_table AS b;
>
> Cross database selects can be accomplished using contrib/dblink.
>
> It will be some time before cross database writes or locks will be
> possible.
>

THANKS!!!! this looks very promising and it seems that there are function available for insert/update/delete.

Again thanks

-Joe

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Rod Taylor wrote:
> On Mon, 2004-03-08 at 11:57, Joe Maldonado wrote:
>> I see that there is an item "Queries across databases or servers
>> (two-phase commit)" on the todo list's urgent header. I have tried
>> asking this question on the other lists and have not yet gotten a
>> suitable answer to this question...When is this functionality
>> expected to be available in PostgreSQL? I as well as many others
>> want to be able to run queries such as
>
> Cross database selects can be accomplished using contrib/dblink.
>
> It will be some time before cross database writes or locks will be
> possible.

Actually cross database writes can also be done with dblink, but without
2PC, or something similar, it is hard to make it bulletproof.

More to the original point, there is no one (that I'm aware of) actively
working on internal backend cross database functionality such as what
the OP seems to be expecting. There has been discussion on this in the
past (see the mail archives), and there is a SQL2003 spec covering it
(see SQL/MED). Patches would be warmly welcomed ;-). If I don't get beat
to it, I might find the time and interest someday, but there is no
"expected" date of arrival.

Joe

On Mon, 8 Mar 2004, Joe Maldonado wrote:

> Hello,
> I see that there is an item "Queries across databases or servers (two-phase commit)" on the todo list's urgent header. I have tried asking this question on the other lists and have not yet gotten a suitable answer to this question...When is this functionality expected to be available in PostgreSQL? I as well as many others want to be able to run queries such as
>
> SELECT a.field_a, b.field_b FROM user:pwd(at)host(dot)database(dot)schema(dot)table_a AS a NATURAL JOIN local_table AS b;

Note that if you can live with having your databases converted into
schemas within the same database, then you can do this now and with all
the performance available by doing it within a single database.