On Wed, May 22, 2019 at 1:52 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: > > On Fri, May 17, 2019 at 6:12 PM Tom Lane <t...@sss.pgh.pa.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
