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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
