Re: Is it safe to ignore the return value of SPI_finish and SPI_execute?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is it safe to ignore the return value of SPI_finish and SPI_execute?
Date: 2019-05-23 16:48:49
Message-ID: 14823.1558630129@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-23 16:50:53 Re: nitpick about useless floating point division in gimme_edge_table
Previous Message Mark Dilger 2019-05-23 16:10:35 Question about BarrierAttach spinlock