SPI refactoring - Mailing list pgsql-hackers

From Mark Dilger
Subject SPI refactoring
Date
Msg-id cc57ea5c-592a-6c27-aca6-7ad2a166c379@gmail.com
Whole thread Raw
Responses Re: SPI refactoring  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: SPI refactoring  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Hackers,

As discussed with Tom in [1] and again with Pavel and Alvaro in [2], 
here is a partial WIP refactoring of the SPI interface.  The goal is to 
remove as many of the SPI_ERROR_xxx codes as possible from the 
interface, replacing them with elog(ERROR), without removing the ability 
of callers to check meaningful return codes and make their own decisions 
about what to do next.  The crucial point here is that many of the error 
codes in SPI are "can't happen" or "you made a programmatic mistake" 
type errors that don't require run time remediation, but rather require 
fixing the C code and recompiling.  Those seem better handled as an 
elog(ERROR) to avoid the need for tests against such error codes 
sprinkled throughout the system.

One upshot of the refactoring is that some of the SPI functions that 
previously returned an error code can be changed to return void.  Tom 
suggested a nice way to use macros to provide backward compatibility 
with older third-party software, and I used his suggestion.

I need guidance with SPI_ERROR_ARGUMENT because it is used by functions 
that don't return an integer error code, but rather return a SPIPlanPtr, 
such as SPI_prepare.  Those functions return NULL and set a global 
variable named SPI_result to the error code.  I'd be happy to just 
convert this to throwing an error, too, but it is a greater API break 
than anything implemented in the attached patches so far.  How do others 
feel about it?

If more places like this can be converted to use elog(ERROR), it may be 
possible to convert more functions to return void.


[1] https://www.postgresql.org/message-id/13404.1558558354%40sss.pgh.pa.us

[2] 
https://www.postgresql.org/message-id/20191106151112.GA12251%40alvherre.pgsql
-- 
Mark Dilger

Attachment

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: TestLib::command_fails_like enhancement
Next
From: Andres Freund
Date:
Subject: Re: log bind parameter values on error