Skip site navigation (1) Skip section navigation (2)

Re: BUG #3040: Domain type handling change in 8.2.2 breaks declarations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dreas Nielsen" <dreas(dot)nielsen(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3040: Domain type handling change in 8.2.2 breaks declarations
Date: 2007-02-23 04:48:06
Message-ID: 11426.1172206086@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Dreas Nielsen" <dreas(dot)nielsen(at)gmail(dot)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

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2007-02-23 04:54:08
Subject: Re: BUG #3037: strange behave of CHECK constraint
Previous:From: Raymond NaseefDate: 2007-02-23 03:15:50
Subject: BUG #3059: psql to 'postgres' shortcut

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group