| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Bryn Llewellyn <bryn(at)yugabyte(dot)com> |
| Cc: | pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: "A transaction cannot be ended inside a block with exception handlers." |
| Date: | 2022-05-07 00:14:54 |
| Message-ID: | CAKFQuwbjWf2FTUruGzhx--f74ctw0MRLf_DwBXk0JO1LMnLx_A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, May 6, 2022 at 4:40 PM Bryn Llewellyn <bryn(at)yugabyte(dot)com> wrote:
>
> Is there simply no way that inserts into table "t" in my example can be
> encapsulated in PL/pgSQL so that the error from the failing trigger can be
> handled rather there than escaping, raw, to the client?
>
>
Any potential solution to this problem will involve writing a stored
procedure (CREATE PROCEDURE) which becomes the API layer for the
application and each one probably issues a commit just prior to returning
control to the calling application. Its exception handler can transform
the at-commit errors to application errors and then return control to the
calling application - which then needs to handle a clean return or an
application-level error return.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rama Krishnan | 2022-05-07 00:23:38 | Vertical partition |
| Previous Message | Bryn Llewellyn | 2022-05-06 23:40:03 | "A transaction cannot be ended inside a block with exception handlers." |