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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
