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
18 matches
Mail list logo
