Re: Speed dblink using alternate libpq tuple storage - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Speed dblink using alternate libpq tuple storage
Date
Msg-id CA+TgmoZF8HUO__0O9gomw66bPDeTNCbXYVAuT385iMx9pgmv5w@mail.gmail.com
Whole thread Raw
In response to Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
List pgsql-hackers
On Tue, Feb 7, 2012 at 9:44 AM, Marko Kreen <markokr@gmail.com> wrote:
>> - What is the right (or recommended) way to prevent from throwing
>> exceptoin in row-processor callback function?  When author should use
>> PG_TRY block to catch exception in the callback function?
>
> When it calls backend functions that can throw exceptions?
> As all handlers running in backend will want to convert data
> to Datums, that means "always wrap handler code in PG_TRY"?

I would hate to have such a rule.  PG_TRY isn't free, and it's prone
to subtle bugs, like failing to mark enough stuff in the same function
"volatile".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: sujayr06
Date:
Subject: Can PQstatus() be used by Application to check connection to postgres periodically?
Next
From: Robert Haas
Date:
Subject: Re: patch for parallel pg_dump