On 2019-May-22, Mark Dilger wrote:
> On Wed, May 22, 2019 at 1:52 PM Tom Lane wrote:
> > Figuring out what fraction
> > that should be is part of the work --- but just in a quick scan through
> > spi.c, it seems like there might be a case for deprecating practically
> > all the SPI_ERROR_xxx
I wrote:
> It's not entirely clear to me whether we ought to change the return
> convention to be "returns void" or make it "always returns SPI_OK"
> for those functions where the return code becomes trivial. The
> latter would avoid churn for external modules, but it seems not to
> have much
On Wed, May 22, 2019 at 1:52 PM Tom Lane wrote:
>
> Mark Dilger writes:
> > On Fri, May 17, 2019 at 6:12 PM Tom Lane wrote:
> >> One reasonable solution would be to change the callers that got this
> >> wrong. Another one would be to reconsider whether the error-return-code
> >> convention
Mark Dilger writes:
> On Fri, May 17, 2019 at 6:12 PM Tom Lane wrote:
>> One reasonable solution would be to change the callers that got this
>> wrong. Another one would be to reconsider whether the error-return-code
>> convention makes any sense at all here. If we changed the above-quoted
>>
On Fri, May 17, 2019 at 6:12 PM Tom Lane wrote:
>
> Mark Dilger writes:
> > most places that use SPI_connect ... SPI_finish check the
> > return value of SPI_finish and elog if it failed. There
> > are a few places that do not, and it is unclear to me
> > why this is safe. SPI_finish appears
Mark Dilger writes:
> most places that use SPI_connect ... SPI_finish check the
> return value of SPI_finish and elog if it failed. There
> are a few places that do not, and it is unclear to me
> why this is safe. SPI_finish appears to be needed to
> clean up memory contexts.
Well, looking
Hackers,
most places that use SPI_connect ... SPI_finish check the
return value of SPI_finish and elog if it failed. There
are a few places that do not, and it is unclear to me
why this is safe. SPI_finish appears to be needed to
clean up memory contexts.
Examples can be found in:
