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
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 |