Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] dblink: rollback transaction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org,Oleg Lebedev <oleg(dot)lebedev(at)waterford(dot)org>
Subject: Re: [GENERAL] dblink: rollback transaction
Date: 2004-02-23 04:32:00
Message-ID: 20819.1077510720@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-patches
Joe Conway <mail(at)joeconway(dot)com> writes:
> One question that I'd like some feedback on is the following: should the 
> same change be applied to other functions that might throw an ERROR 
> based on the remote side of the connection? For example, currently if 
> dblink() is used in an attempt to access a non-existent remote table, an 
> ERROR is thrown locally in response, killing any currently open 
> transaction. Thoughts?

It seems like a good idea to offer a consistent policy about this.
But I'm not sure that you should make a 180-degree change in error
handling without any backward-compatibility option.  (In view of
recent discussions, the phrase "GUC variable" will not cross my
lips here.)

What seems like a good idea after a few moments' thought is to leave the
behavior of the various dblink_foo() functions the same as now (ie,
throw error on remote error) and add new API functions named something
like dblink_foo_noerror() that don't throw error but return a
recognizable failure code instead.  My argument for this approach is
that there is no situation in which the programmer shouldn't have to
think when he writes a given call whether it will elog or return an
error indicator, because if he wants an error indicator then he is going
to have to check for it.

I'm not wedded to that in particular, but I do think you need to offer
a consistent approach with reasonable regard to backwards compatibility.
If you apply the patch as given you will surely be breaking existing
callers ... what's worse, the breakage is silent, and will only show up
under stress in the field.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Andrew DunstanDate: 2004-02-23 18:09:06
Subject: log_line_info
Previous:From: Tom LaneDate: 2004-02-23 03:15:07
Subject: Re: dblink - custom datatypes NOW work :)

pgsql-general by date

Next:From: Richard HuxtonDate: 2004-02-23 07:58:30
Subject: Re: System tuning
Previous:From: Tom LaneDate: 2004-02-23 03:15:07
Subject: Re: dblink - custom datatypes NOW work :)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group