SPI refactoring

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема SPI refactoring
Дата
Msg-id cc57ea5c-592a-6c27-aca6-7ad2a166c379@gmail.com
обсуждение исходный текст
Ответы Re: SPI refactoring  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: SPI refactoring  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: TestLib::command_fails_like enhancement
Следующее
От: Andres Freund
Дата:
Сообщение: Re: log bind parameter values on error