Re: SPI_connect, SPI_connect_ext return type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Stepan <sndcppg(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SPI_connect, SPI_connect_ext return type
Date: 2024-08-10 16:29:04
Message-ID: 3155777.1723307344@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Saturday, August 10, 2024, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2024-08-10 16:33:57 Re: [HACKERS] make async slave to wait for lsn to be replayed
Previous Message Alexander Korotkov 2024-08-10 15:58:31 Re: [HACKERS] make async slave to wait for lsn to be replayed