Tom Lane wrote:
> 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?
> 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 like the idea in general, but maybe instead there should be a new
overloaded version of the existing function names that accepts an
additional bool argument. Without the argument, behavior would be as it
is now; with it, you could specify the old or new behavior.
Joe
