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

Re: union bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ivan <Ivan-Sun1(at)mail(dot)ru>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: union bug
Date: 2005-10-19 16:03:05
Message-ID: 22267.1129737785@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Ivan <Ivan-Sun1(at)mail(dot)ru> writes:
> CREATE DOMAIN test_domain
>   AS varchar(64)
>   NOT NULL;
  
> CREATE TYPE test_type AS
>    ("Id" int4,
>     "Data" test_domain);

> CREATE OR REPLACE FUNCTION union_test()
>   RETURNS SETOF test_type AS
> $BODY$
>     select 1 as "Id", 'string1'::test_domain as "Data"
>     union all
>     select 2 as "Id", 'string2'::test_domain as "Data"
> $BODY$
>   LANGUAGE 'sql' VOLATILE;

> generates error message

> ERROR:  return type mismatch in function declared to return test_type
> DETAIL:  Final SELECT returns character varying instead of test_domain at column 2.
> CONTEXT:  SQL function "union_test"

The reason this happens is that select_common_type() smashes all its
inputs down to base types.  I'm a bit hesitant to change this behavior
without thinking about all the possible consequences.  There are clearly
some cases where it's the right thing --- for instance, if the inputs
are two different domains over the same base type, selecting the base
type seems the most reasonable behavior.  Also, at least some of the
routine's callers seem to be relying on the assumption that the result
won't be a domain type.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2005-10-19 16:12:08
Subject: Re: BUG #1976: steps to reproduce BUG #1438: Non UTF-8 client encoding problem
Previous:From: Richard HuxtonDate: 2005-10-19 16:02:46
Subject: Function taking compound type defined on a view with ORDER BY

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