Re: [HACKERS] Getting rid of "unknown error" in dblink andpostgres_fdw

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: [HACKERS] Getting rid of "unknown error" in dblink andpostgres_fdw
Дата
Msg-id b319d233-d57a-abbd-6f6d-1359b10d56f6@joeconway.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Logical decoding on standby
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: [HACKERS] [bug fix] Trivial ecpg bug which can cause memory overrun