Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> [ 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
>>
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Tom Lane <[EMAIL PROTECTED]> 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 th
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> * tupdesc has fewer columns than the tuple does. I think this can
>> happen in certain inheritance cases --- we might be inspecting a child
>> tuple using a parent's tupdesc.
> There are some comments in the sourc
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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. Throwin
Tom Lane <[EMAIL PROTECTED]> 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. The code perhap
The various exported functions in spi.c that take an attribute number
are not consistent about how they range-check it --- some test against
tupdesc->natts and some against HeapTupleHeaderGetNatts(tuple).
(Look for references to SPI_ERROR_NOATTRIBUTE to see what I'm talking
about.)
I'm thinking th
