Re: Bogus attribute-number range checks in spi.c

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> * tupdesc has more columns than the tuple does. This is possible after
>>> ALTER TABLE ADD COLUMN, for example. The correct interpretation in
>>> this situation is that the extra columns exist but are NULL. Throwing
>>> an error is not correct.
>
>> Shouldn't this be failing then? If something like this does fail then
>> definitely back-patchable++.
>
> [ pokes around ... ] The difference between correct and incorrect
> behavior here is that it is correct for SPI_getvalue and SPI_getbinval
> to return NULL for added columns, but they are incorrect to also set
> SPI_result to SPI_ERROR_NOATTRIBUTE. However, so far as I can see
> none of the callers in our CVS bother to check SPI_result :-(. So there
> is no visible failure in any test case using our code. You'd need a
> third-party module that was actually paying attention to the documented
> error-reporting convention.

I do see several checks against SPI_ERROR_NOATTRIBUTE. I'm not sure what
context they're in though. pl_exec.c:3606 and pl_exec.c:3940

I also see tsearch (and tsearch2 and fti) and checking for that error. And
several of the EDB oracle compatibility modules. It seems likely there are
other third party modules which check for this as well.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!