Tom Lane-2 wrote
> In our fine manual, at
> http://www.postgresql.org/docs/devel/static/typeconv-union-case.html
> 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:
http://postgresql.1045698.n5.nabble.com/select-common-type-s-behavior-doesn-t-match-the-documentation-tp5780985p5813963.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
