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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Bogus attribute-number range checks in spi.c
Date: 2008-10-15 02:59:39
Message-ID: 8244.1224039579@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Maybe that means it's not worth back-patching, but it still looks like
a bug to me.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-10-15 03:21:25 Re: Bogus attribute-number range checks in spi.c
Previous Message Gregory Stark 2008-10-15 01:50:54 Re: Bogus attribute-number range checks in spi.c