Re: Is it safe to ignore the return value of SPI_finish and SPI_execute? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Is it safe to ignore the return value of SPI_finish and SPI_execute?
Date
Msg-id 14823.1558630129@sss.pgh.pa.us
Whole thread Raw
In response to Re: Is it safe to ignore the return value of SPI_finish and SPI_execute?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> It's not entirely clear to me whether we ought to change the return
> convention to be "returns void" or make it "always returns SPI_OK"
> for those functions where the return code becomes trivial.  The
> latter would avoid churn for external modules, but it seems not to
> have much other attractiveness.

Further thought about that --- it's clearly better in the long run
if we switch to "returns void" where possible.  We don't want to
encourage people to waste code space on dead error checks.  However,
doing that could be quite a PITA for people who are trying to maintain
extension code that works across multiple backend versions.

We could address that by providing compatibility macros, say per
this sketch:

extern void SPI_finish(void);
...

#ifdef BACKWARDS_COMPATIBLE_SPI_CALLS

#define SPI_finish() (SPI_finish(), SPI_OK_FINISH)
...

#endif

(This relies on non-recursive macro expansion, but that's been
standard since C89.)

The #ifdef stanza could be ripped out someday when all older branches
are out of support, but there wouldn't be any hurry.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Question about BarrierAttach spinlock
Next
From: Tom Lane
Date:
Subject: Re: nitpick about useless floating point division in gimme_edge_table