| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Marko Kreen <markokr(at)gmail(dot)com> |
| Cc: | Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>, mmoncure(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, greg(at)2ndquadrant(dot)com |
| Subject: | Re: Speed dblink using alternate libpq tuple storage |
| Date: | 2012-02-07 15:58:10 |
| Message-ID: | CA+TgmoZF8HUO__0O9gomw66bPDeTNCbXYVAuT385iMx9pgmv5w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 7, 2012 at 9:44 AM, Marko Kreen <markokr(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-02-07 15:59:01 | Re: patch for parallel pg_dump |
| Previous Message | Kevin Grittner | 2012-02-07 15:14:02 | Re: patch for preventing the specification of conflicting transaction read/write options |