From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Getting rid of "unknown error" in dblink and postgres_fdw |
Date: | 2016-12-22 06:04:51 |
Message-ID: | b319d233-d57a-abbd-6f6d-1359b10d56f6@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/21/2016 09:20 PM, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2016-12-22 06:12:58 | [bug fix] Trivial ecpg bug which can cause memory overrun |
Previous Message | Michael Paquier | 2016-12-22 05:43:38 | Re: Logical decoding on standby |