Re: BUG #3040: Domain type handling change in 8.2.2 breaks declarations - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #3040: Domain type handling change in 8.2.2 breaks declarations
Date
Msg-id 11426.1172206086@sss.pgh.pa.us
Whole thread Raw
In response to BUG #3040: Domain type handling change in 8.2.2 breaks declarations  ("Dreas Nielsen" <dreas.nielsen@gmail.com>)
List pgsql-bugs
"Dreas Nielsen" <dreas.nielsen@gmail.com> writes:
> CREATE DOMAIN real_value
>   AS double precision
>   NOT NULL;

> CREATE DOMAIN significant_digits
>   AS integer
>   DEFAULT 2
>   NOT NULL;

> CREATE TYPE measurement_result AS
>    (value real_value,
>     sig_figs significant_digits,
>     std_dev double precision,
>     undetected measurement_qualifier,
>     estimated measurement_qualifier,
>     rejected measurement_qualifier,
>     greater_than measurement_qualifier);

> CREATE OR REPLACE FUNCTION avg_mv_half(currstate measval_accum)
>   RETURNS measurement_result AS
> $BODY$
> DECLARE
>     rv measurement_result;

> The declaration of the variable rv in function avg_mv_half() fails.

AFAICS it should do so, since you neglected to provide a non-null
initial value.

Now there is an implementation deficiency here, since if you try to
fix it:
    rv measurement_result := '(0,0 ...
you get
ERROR:  default value for row or record variable is not supported
CONTEXT:  compile of PL/pgSQL function "avg_mv_half" near line 2
I think that should be fixed, but that's not what you are claiming the
bug is.

> I suggest that restrictions on domain types
> be enforced in the RETURN statement of a plpgsql function rather than in the
> DECLARE statement.

If you don't want the domain restrictions enforced against the temporary
variable, don't declare it as being of the domain type.

Personally I think that NOT NULL domain restrictions are the stupidest
idea I've seen lately, as they break all sorts of behavior, starting with
outer joins.  But if you insist on using one, do not complain when it
gets enforced against you.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #3051: FATAL: too many trigger records found for relation "pg_authid"
Next
From: Tom Lane
Date:
Subject: Re: BUG #3037: strange behave of CHECK constraint