Re: Is it safe to ignore the return value of SPI_finish and SPI_execute?

On Wed, May 22, 2019 at 1:52 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
> > On Fri, May 17, 2019 at 6:12 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
> >> bit to be an ereport(ERROR), then we could say that SPI_finish either
> >> returns 0 or throws error, making it moot whether callers check, and
> >> allowing removal of now-useless checks from all the in-core callers.
>
> > Does this proposal of yours seem good enough for me to make a patch
> > based on this design?
>
> Just to clarify --- I think what's being discussed here is "change some
> large fraction of the SPI functions that can return SPI_ERROR_xxx error
> codes to throw elog/ereport(ERROR) instead".

Yes, I was talking about that, but was ambiguous in how I phrased my
question.

> 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 codes except for SPI_ERROR_NOATTRIBUTE.
> I'd definitely argue that SPI_ERROR_UNCONNECTED and SPI_ERROR_ARGUMENT
> deserve that treatment.
>
> I'm for it, if you want to do the work, but I don't speak for everybody.

I do want to write the patch, but I'll wait for other opinions.

mark