> > select id, null as text from foo union select id, name from 
> foo_child;
> > fails with
> > unable to trasform {insert whatever type here} into unknown
> >          Each UNION | EXCEPT | INTERSECT clause must have 
> compatible target 
> > types
> 
> The UNION type-resolution code could use some work; right now I think
> the algorithm is to use the types of the first SELECT and force
> everything else into that.

Imho this is expected behavior (maybe even standard). Very easy to
understand.
 
> A more symmetrical
> promote-to-common-supertype approach would be nice.

While this sounds sexy it is not what people would expect (imho),
and would have a magic touch to it.

Andreas

Tue, 8 Aug 2000 09:39:55 +0200 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: UNIONS 
Zeugswetter Andreas SB <ZeugswetterA@Wien.Spardat.at> writes:
>> The UNION type-resolution code could use some work; right now I think
>> the algorithm is to use the types of the first SELECT and force
>> everything else into that.

> Imho this is expected behavior (maybe even standard).

Wrong.  Read the spec (see 9.3 in SQL99).

			regards, tom lane

Tue, 08 Aug 2000 09:21:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: UNIONS 