Re: [HACKERS] Getting rid of "unknown error" in dblink andpostgres_fdw - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [HACKERS] Getting rid of "unknown error" in dblink andpostgres_fdw
Date
Msg-id b319d233-d57a-abbd-6f6d-1359b10d56f6@joeconway.com
Whole thread Raw
In response to Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw
List pgsql-hackers
On 12/21/2016 09:20 PM, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> On 12/21/2016 04:22 PM, Tom Lane wrote:
>>> In short, yes, please copy that bit into dblink.
>
>> The attached should do the trick I think.
>
> I see that you need to pass the PGconn into dblink_res_error() now, but
> what's the point of the new "bool fail" parameter?

That part isn't new -- we added it sometime prior to 9.2:

8<--------------if (fail)    level = ERROR;else    level = NOTICE;
8<--------------

It allows dblink to throw a NOTICE on remote errors rather than an
actual ERROR, e.g. for an autonomous transaction.

From the docs (9.2 in this case)
8<--------------
fail_on_error
   If true (the default when omitted) then an error thrown on the
remote side of the connection causes an error to also be thrown locally.
If false, the remote error is locally reported as a NOTICE, and the
function returns no rows.
8<--------------

>> You think it is reasonable to backpatch this part too?
>
> Yes, definitely.

Ok, will do.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Logical decoding on standby
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: [HACKERS] [bug fix] Trivial ecpg bug which can cause memory overrun