Thread: How to know if SPI or some other API triggered an ERROR.

How to know if SPI or some other API triggered an ERROR.

From
"dandl"
Date:

The question is whether there is any way to know that some Postgres API call such as SPI (or others) did not return but instead triggered an elog(ERROR).

 

The context is the implementation of a language handler (plandl for Andl) with the possibility of re-entrant calls to functions. I would like to be able to recover from Postgres errors, but that’s quite difficult if I don’t know that one has happened, particularly if it happens inside a nested call that needs to be unwound.

 

Any suggestions appreciated.

 

Regards

David M Bennett FACS


Andl - A New Database Language - andl.org

 

Re: How to know if SPI or some other API triggered an ERROR.

From
Tom Lane
Date:
"dandl" <david@andl.org> writes:
> The question is whether there is any way to know that some Postgres API call such as SPI (or others) did not return
butinstead triggered an elog(ERROR). 

I think what you're looking for is to set up a PG_TRY/PG_CATCH block to
intercept the error as the stack is being unwound.

            regards, tom lane


Re: How to know if SPI or some other API triggered an ERROR.

From
"dandl"
Date:
Thanks. Yes, I have seen those around and kind of wondered.

It looks like it can only be used in a "C" context. Should do what I need,
if I can find the right place to put it.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org



> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Sunday, 22 May 2016 12:01 AM
> To: dandl <david@andl.org>
> Cc: 'PostgreSQL' <pgsql-general@postgresql.org>
> Subject: Re: [GENERAL] How to know if SPI or some other API triggered an
> ERROR.
>
> "dandl" <david@andl.org> writes:
> > The question is whether there is any way to know that some Postgres API
> call such as SPI (or others) did not return but instead triggered an
> elog(ERROR).
>
> I think what you're looking for is to set up a PG_TRY/PG_CATCH block to
> intercept the error as the stack is being unwound.
>
>             regards, tom lane