Re: missing "SPI_finish" that isn't missing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: missing "SPI_finish" that isn't missing
Date
Msg-id 19080.1450993074@sss.pgh.pa.us
Whole thread Raw
In response to missing "SPI_finish" that isn't missing  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: missing "SPI_finish" that isn't missing  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> I probably just need to learn the right coding pattern for this.
> What is it?

You can't just ignore a thrown error like that.  What you'd have to do
to make this coding pattern work is to set up a subtransaction, and either
commit it in the success path or roll it back upon catching an error.
(This is not terribly well documented, but the exception-block handling
in plpgsql provides a working model to follow.)  Without subtransaction
cleanup, lots of stuff will be left in incorrect states --- the unbalanced
SPI stack you're seeing is just the tip of the iceberg.

99% of the time, the path of least resistance at the C-code level is to
avoid expected error conditions in the first place, rather than try to
catch and clean up.  In this example, there are plenty of ways you might
test whether "mytable" exists before risking the SPI_execute call.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Emre Hasegeli
Date:
Subject: Re: BRIN cost estimate
Next
From: Thomas Munro
Date:
Subject: Re: Support for N synchronous standby servers - take 2