Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Tom Lane wrote:
>> exec_move_row() should be more forgiving of tuples with a different
>> number of columns than it was expecting, for reasons that are now
>> documented in the code...
> Does your change take multiple inheritance into account ?
It does not, but it's not any more broken than before for that case.
In particular, it's exactly as broken as SQL-language functions,
which also can fail in multiple inheritance situations:
regression=# create table tab1(f1 int);
CREATE
regression=# create table tab2(f2 float8);
CREATE
regression=# create table tab3(f3 int) inherits(tab2,tab1);
CREATE
regression=# \d tab3
Table "tab3"
Attribute | Type | Modifier
-----------+------------------+----------
f2 | double precision |
f1 | integer |
f3 | integer |
regression=# insert into tab3 values(2.2,1,3);
INSERT 2193143 1
regression=# select f1 from tab3;
f1
----
1
(1 row)
regression=# create function getf1(tab1) returns int as
regression-# 'select $1.f1' language 'sql';
CREATE
regression=# select getf1(tab3) from tab3;
getf1
------------
1074683344
(1 row)
In fact plpgsql's behavior is now a little better than SQL's,
because at least it notices that it's got the wrong type and
tries to do a type conversion:
regression=# drop function getf1(tab1);
DROP
regression=# create function getf1(tab1) returns int as
regression-# 'begin return $1.f1; end;' language 'plpgsql';
CREATE
regression=# select getf1(tab3) from tab3;
ERROR: pg_atoi: error in "2.2": can't parse ".2"
If you feel inclined to do something about this for 7.2,
go right ahead --- making it work for single inheritance
was all that I was concerned about.
regards, tom lane