Joe Conway <mail@joeconway.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
