Tom Lane <tgl@sss.pgh.pa.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. 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.
Shouldn't this be failing then? If something like this does fail then
definitely back-patchable++.
postgres=# create table t (i integer);
CREATE TABLE
postgres=# insert into t values (0);
INSERT 0 1
postgres=# alter table t add j integer;
ALTER TABLE
postgres=# create function x() returns integer as 'declare v integer; begin select j from t where i = 0 into v; return
v;end' language plpgsql;
CREATE FUNCTION
postgres=# select x();x
---
(1 row)
> * 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.
There are some comments in the source about cases like this but I've never
understood how it can happen. Children are supposed to have a superset of the
parent's columns. Does it depend on the parent having had dropped columns but
not the child? But then wouldn't the Append node have had to do some magic to
map the columns correctly meaning you wouldn't be looking at the physical
tuple any more?
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
