Re: SPI_connect, SPI_connect_ext return type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SPI_connect, SPI_connect_ext return type
Date
Msg-id 3155777.1723307344@sss.pgh.pa.us
Whole thread Raw
In response to Re: SPI_connect, SPI_connect_ext return type  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: SPI_connect, SPI_connect_ext return type
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Saturday, August 10, 2024, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That would break a lot of code (much of it not under our control) to
>> little purpose; it would also foreclose the option to return to using
>> SPI_ERROR_CONNECT someday.

> I suggest we document it as deprecated and insist any future attempt to
> implement a return-on-error connection function define a completely new
> function.

True; we're kind of in an intermediate place right now where certain
call sites aren't bothering to check the return code, but it's hard
to argue that they're really wrong --- and more to the point,
re-introducing use of SPI_ERROR_CONNECT would break them.  I don't
know if that usage pattern has propagated outside Postgres core,
but it might've.  Perhaps it would be better to update the docs to
say that the only return value is SPI_OK_CONNECT and all failure
cases are reported via elog/ereport.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Next
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed