Tom Lane-2 wrote
> In our fine manual, at
> it's claimed that the nontrivial parts of UNION type resolution
> work like this:
>   4. Choose the first non-unknown input type which is a preferred type in
>   that category, if there is one.
>   5. Otherwise, choose the last non-unknown input type that allows all the
>   preceding non-unknown inputs to be implicitly converted to it. (There
>   always is such a type, since at least the first type in the list must
>   satisfy this condition.)
> This came up because some of my Salesforce colleagues were griping about
> the fact that UNION isn't commutative.  They argue that the type
> resolution behavior ought not be sensitive at all to the ordering of the
> inputs.  I'm not sure we can achieve that in general, but the current
> approach certainly seems more order-sensitive than it oughta be.

4. Use the preferred type for whatever category all inputs share (per 3). 
Per 1 this is only used if at least one input does not agree.

5. No longer needed

6. Stays the same

It is possible for a result type to not match any of the input types but if
you want to be commutative this would have to be allowed.

You could add a "majority rules" condition rules before 4 and punt if there
is no one dominate type.

Should #1 repeat after flattening domains to their base types?

I would probably logically place 2 before 1 since if everything is unknown
nothing else matters.

David J.

View this message in context:
Sent from the PostgreSQL - hackers mailing list archive at

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to