From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Bogus attribute-number range checks in spi.c |
Date: | 2008-10-14 23:40:53 |
Message-ID: | 2246.1224027653@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 that the former is correct and the latter is simply wrong.
There are two possible cases:
* 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 perhaps thinks it's protecting
heap_getattr against an out-of-range attnum, but heap_getattr is
supposed to take care of itself that way.
* 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. Whether it's possible or not, it's
simply wrong for the code to use the larger number, as that would result
in accessing off the end of the tupdesc's attribute array.
So I think this needs to be made consistent, and furthermore that it's
a backpatchable bug fix. Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-10-14 23:57:12 | Re: Improving planner variable handling |
Previous Message | Bruce Momjian | 2008-10-14 23:17:44 | Re: db_user_namespace, md5 and changing passwords |