On Wed, 2009-09-16 at 13:47 +0900, Itagaki Takahiro wrote:
> Peter Eisentraut wrote:
>
> > This patch is listed in the commitfest, but I think the consensus was
> > that it needed some rework.
>
> No doubt, but SQL/MED will require a lot of works. Can we split the work
> into small parts? I inte
Peter Eisentraut wrote:
> This patch is listed in the commitfest, but I think the consensus was
> that it needed some rework.
No doubt, but SQL/MED will require a lot of works. Can we split the work
into small parts? I intended FDW-based dblink to be one of the split jobs.
Here are some random
On Wed, 2009-08-19 at 17:07 +0900, Itagaki Takahiro wrote:
> Here is a WIP patch for a foreign data wrapper based dblink.
>
> It integrates dblink module into core and adds a new functionality,
> automatic transaction management. The new interface of dblink is
> exported by include/foreign/dblink.
Itagaki Takahiro wrote:
> However, automatic transaction management needs help by core. Is it
> acceptable to have two-phase callbacks?
Probably, but it's far too early to decide what the interface should
look like.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent v
Tom Lane wrote:
> I don't believe there is any consensus for integrating dblink into core,
> and I for one will resist that strongly. Keep it in contrib.
OK, our consensus is that dblink should be replaced with SQL/MED interface
and then we'll start to consider integrating into core.
However,
Tom Lane wrote:
> Pavel Stehule writes:
>> 2009/8/19 Tom Lane :
>>> I don't believe there is any consensus for integrating dblink into core,
>>> and I for one will resist that strongly. Â Keep it in contrib.
>
>> if integration means, so I could to write query like
>> SELECT * FROM otherdatabase.
2009/8/19 Tom Lane :
> Pavel Stehule writes:
>> 2009/8/19 Tom Lane :
>>> I don't believe there is any consensus for integrating dblink into core,
>>> and I for one will resist that strongly. Keep it in contrib.
>
>> if integration means, so I could to write query like
>> SELECT * FROM otherdataba
Itagaki Takahiro wrote:
> It integrates dblink module into core and adds a new functionality,
> automatic transaction management.
Why does it need to be integrated to core? I'd prefer to keep dblink out
of core, unless there's a reason.
> I want pretty much the automatic transaction management. I
Pavel Stehule writes:
> 2009/8/19 Tom Lane :
>> I don't believe there is any consensus for integrating dblink into core,
>> and I for one will resist that strongly. Â Keep it in contrib.
> if integration means, so I could to write query like
> SELECT * FROM otherdatabase.schema.table
> UPDAT
2009/8/19 Tom Lane :
> Itagaki Takahiro writes:
>> Here is a WIP patch for a foreign data wrapper based dblink.
>> It integrates dblink module into core and adds a new functionality,
>> automatic transaction management.
>
> I don't believe there is any consensus for integrating dblink into core,
>
Itagaki Takahiro writes:
> Here is a WIP patch for a foreign data wrapper based dblink.
> It integrates dblink module into core and adds a new functionality,
> automatic transaction management.
I don't believe there is any consensus for integrating dblink into core,
and I for one will resist that
Heikki Linnakangas wrote:
> In fact, by using 2PC without a recovery system you
> can end up with a transaction that's prepared but never committed or
> aborted, requiring an admin to remove it manually, which is even worse than
> not using 2PC to begin with.
Yes, true. But I think "hard-to-use
2009/8/14 Itagaki Takahiro
>
> Heikki Linnakangas wrote:
>
> > Quite aside from the requirement for on-commit trigger, how exactly
> > would you use 2PC with the remote database? When would you issue PREPARE
> > TRANSACTION, and when would COMMIT PREPARED? What if the local database
> > crashes
Heikki Linnakangas wrote:
> Quite aside from the requirement for on-commit trigger, how exactly
> would you use 2PC with the remote database? When would you issue PREPARE
> TRANSACTION, and when would COMMIT PREPARED? What if the local database
> crashes in between - is the remote transaction le
Alvaro Herrera wrote:
> > int64 exec(self, query);/* for UPDATE, INSERT, DELETE
> > */
>
> It's not good to return int64 in exec(), because it could have a
> RETURNING clause. (So it also needs a fetchsize).
We should use open() for RETURNING query.
It is just same as p
On Thu, Aug 13, 2009 at 02:01:19PM +0300, Heikki Linnakangas wrote:
> Itagaki Takahiro wrote:
> > Present dblink is a thin wrapper of libpq, but some of my customers
> > want automatic transaction managements. Remote transactions are
> > committed with 2PC when the local transaction is committed.
>
Itagaki Takahiro wrote:
> Also new two interfaces will be introduced:
>
> interface Connection/* represents PGconn */
> {
> voiddisconnect(self);
> Cursor *open(self, query, fetchsize); /* for SELECT */
> int64 exec(self, query);/* for UPDATE,
Itagaki Takahiro wrote:
> Present dblink is a thin wrapper of libpq, but some of my customers
> want automatic transaction managements. Remote transactions are
> committed with 2PC when the local transaction is committed.
> To achieve it, I think we need on-commit trigger is needed,
> but it is har
Here is a proposal to integrate contrib/dblink and SQL/MED (foreign
data wrapper).
Dblink manages connections and transactions by itself at the moment,
but there are some benefits to split database connectors into FDW.
Dblink will uses those multiple connectors. For example, we will be
able to ret
19 matches
Mail list logo
