Re: FDW for PostgreSQL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FDW for PostgreSQL
Date
Msg-id 26979.1364479867@sss.pgh.pa.us
Whole thread Raw
In response to Re: FDW for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
Responses Re: FDW for PostgreSQL
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> Apologies for bringing this up pretty late, but wrt writable FDW
> transaction levels, I was *really* hoping that we'd be able to implement
> autonomous transactions on top of writeable FDWs.  It looks like there's
> no way to do this using the postgres_fdw due to it COMMIT'ing only when
> the client transaction commits.  Would it be possible to have a simply
> function which could be called to say "commit the transaction on the
> foreign side for this server/table/connection/whatever"?  A nice
> addition on top of that would be able to define 'auto-commit' for a
> given table or server.

TBH I think this is a fairly bad idea.  You can get that behavior via
dblink if you need it, but there's no way to do it in an FDW without
ending up with astonishing (and not in a good way) semantics.  A commit
would force committal of everything that'd been done through that
connection, regardless of transaction/subtransaction structure up to
that point; and it would also destroy open cursors.  The only way to
make this sane at all would be to provide user control of which
operations go to which connections; which is inherent in dblink's API
but is simply not a concept in the FDW universe.  And I don't want to
try to plaster it on, either.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
Next
From: Robert Haas
Date:
Subject: Re: [sepgsql 1/3] add name qualified creation label