Bogus attribute-number range checks in spi.c

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

Responses

Browse pgsql-hackers by date

  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