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

From David G. Johnston
Subject Re: SPI_connect, SPI_connect_ext return type
Date
Msg-id CAKFQuwbKhyAUfZYK2ZpkWWB2dW9p-Xu9DR1Vg5_oOWwgnWmogg@mail.gmail.com
Whole thread Raw
In response to Re: SPI_connect, SPI_connect_ext return type  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SPI_connect, SPI_connect_ext return type
List pgsql-hackers
On Sat, Aug 10, 2024 at 9:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"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.

I don't
know if that usage pattern has propagated outside Postgres core,
but it might've.

I'd give it decent odds since our example usage doesn't include the test.


    /* Convert given text object to a C string */
    command = text_to_cstring(PG_GETARG_TEXT_PP(0));
    cnt = PG_GETARG_INT32(1);

    SPI_connect();

    ret = SPI_exec(command, cnt);

    proc = SPI_processed;

David J.

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Next
From: Noah Misch
Date:
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)