Re: pgsql/src/pl/plpgsql/src pl_exec.c

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