Re: SPI_connect, SPI_connect_ext return type
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Stepan <sndcppg@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-09-05T21:13:50Z
Lists: pgsql-hackers
Attachments
- v1-0001-deprecate-checking-SPI_connect-result.patch (text/x-diff) patch v1-0001
Peter Eisentraut <peter@eisentraut.org> writes: > On 10.08.24 16:12, Tom Lane wrote: >> We go to a lot of effort to keep the SPI API as stable as we can >> across major versions, so I don't see why we'd just randomly make >> an API-breaking change like this. > Here is a previous discussion: > https://www.postgresql.org/message-id/flat/1356682025.20017.4.camel%40vanquo.pezone.net > I like the idea that we would keep the API but convert most errors to > exceptions. After thinking about this for awhile, one reason that it's practical to change it today for SPI_connect is that SPI_connect has not returned anything except SPI_OK_CONNECT since v10. So if we tell extension authors they don't need to check the result, it's unlikely that that will cause any new code they write to get used with PG versions where it would be wrong. I fear that we'd need a similar multi-year journey to get to a place where we could deprecate checking the result of any other SPI function. Nonetheless, there seems no reason not to do it now for SPI_connect. So attached is a patch that documents the result value as vestigial and removes the calling-code checks in our own code, but doesn't touch SPI_connect[_ext] itself. This combines portions of Stepan's two patches with some additional work (mostly, that he'd missed fixing any of contrib/). regards, tom lane
Commits
-
Don't bother checking the result of SPI_connect[_ext] anymore.
- 218527d01456 18.0 landed