NOT NULL constraint vs. composite type (vs. plpgsql)

Some of this behaviour (the plpgsql stuff) could be considered a bug,
but given the differences between pg's behaviour and the spec, the
expected behaviour probably needs to be thrashed out first (which is
why I didn't post this directly to -bugs).

Given (in 8.3.6):

create type ftype as (a integer, b integer);
create table ftbl (x ftype not null);

-- spec says that this should fail, we agree:
insert into ftbl values (null);

-- spec says this should fail, we allow it:
insert into ftbl values (ROW(null,null));

-- spec says this should fail, we allow it:
insert into ftbl values (ROW(1,null));

-- spec says this should be ok, we agree:
insert into ftbl values (ROW(1,2)); 

Given in addition:

create function ffunc1(x1 ftype) returns void language sql as $f$ insert into ftbl values ($1); $f$;

create function ffunc2(x1 ftype) returns void language plpgsql as $f$ begin insert into ftbl values (x1); end; $f$;

select ffunc1(null);  -- fails as expected
select ffunc1(ROW(null,null));  -- succeeds, consistent with plain SQL

select ffunc2(null);  -- succeeds, inconsistently with plain SQL
select ffunc2(ROW(null,null));  -- succeeds

(The spec defines the column constraint NOT NULL as being equivalent to
the table constraint CHECK (columnname IS NOT NULL).  Using the check
constraint explicitly gives the spec's required behaviour in all cases,
as far as I can tell.)

-- 
Andrew (irc:RhodiumToad)