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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Is it safe to ignore the return value of SPI_finish and SPI_execute?
Дата
Msg-id 14823.1558630129@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Is it safe to ignore the return value of SPI_finish and SPI_execute?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Question about BarrierAttach spinlock
Следующее
От: Tom Lane
Дата:
Сообщение: Re: nitpick about useless floating point division in gimme_edge_table