<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML ><HEAD ><TITLE >UNION, CASE, and Related Constructs</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK REV="MADE" HREF="mailto:pgsql-docs@postgresql.org"><LINK REL="HOME" TITLE="PostgreSQL 9.6.17 Documentation" HREF="index.html"><LINK REL="UP" TITLE="Type Conversion" HREF="typeconv.html"><LINK REL="PREVIOUS" TITLE="Value Storage" HREF="typeconv-query.html"><LINK REL="NEXT" TITLE="Indexes" HREF="indexes.html"><LINK REL="STYLESHEET" TYPE="text/css" HREF="stylesheet.css"><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"><META NAME="creation" CONTENT="2020-02-15T12:30:38"></HEAD ><BODY CLASS="SECT1" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="4" ALIGN="center" VALIGN="bottom" ><A HREF="index.html" >PostgreSQL 9.6.17 Documentation</A ></TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A TITLE="Value Storage" HREF="typeconv-query.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A HREF="typeconv.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="60%" ALIGN="center" VALIGN="bottom" >Chapter 10. Type Conversion</TD ><TD WIDTH="20%" ALIGN="right" VALIGN="top" ><A TITLE="Indexes" HREF="indexes.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A NAME="TYPECONV-UNION-CASE" >10.5. <TT CLASS="LITERAL" >UNION</TT >, <TT CLASS="LITERAL" >CASE</TT >, and Related Constructs</A ></H1 ><P >SQL <TT CLASS="LITERAL" >UNION</TT > constructs must match up possibly dissimilar types to become a single result set. The resolution algorithm is applied separately to each output column of a union query. The <TT CLASS="LITERAL" >INTERSECT</TT > and <TT CLASS="LITERAL" >EXCEPT</TT > constructs resolve dissimilar types in the same way as <TT CLASS="LITERAL" >UNION</TT >. The <TT CLASS="LITERAL" >CASE</TT >, <TT CLASS="LITERAL" >ARRAY</TT >, <TT CLASS="LITERAL" >VALUES</TT >, <CODE CLASS="FUNCTION" >GREATEST</CODE > and <CODE CLASS="FUNCTION" >LEAST</CODE > constructs use the identical algorithm to match up their component expressions and select a result data type.</P ><DIV CLASS="PROCEDURE" ><P ><B >Type Resolution for <TT CLASS="LITERAL" >UNION</TT >, <TT CLASS="LITERAL" >CASE</TT >, and Related Constructs</B ></P ><OL TYPE="1" ><LI CLASS="STEP" ><P >If all inputs are of the same type, and it is not <TT CLASS="TYPE" >unknown</TT >, resolve as that type.</P ></LI ><LI CLASS="STEP" ><P >If any input is of a domain type, treat it as being of the domain's base type for all subsequent steps. <A NAME="AEN25658" HREF="#FTN.AEN25658" ><SPAN CLASS="footnote" >[1]</SPAN ></A ></P ></LI ><LI CLASS="STEP" ><P >If all inputs are of type <TT CLASS="TYPE" >unknown</TT >, resolve as type <TT CLASS="TYPE" >text</TT > (the preferred type of the string category). Otherwise, <TT CLASS="TYPE" >unknown</TT > inputs are ignored.</P ></LI ><LI CLASS="STEP" ><P >If the non-unknown inputs are not all of the same type category, fail.</P ></LI ><LI CLASS="STEP" ><P >Choose the first non-unknown input type which is a preferred type in that category, if there is one.</P ></LI ><LI CLASS="STEP" ><P >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.)</P ></LI ><LI CLASS="STEP" ><P >Convert all inputs to the selected type. Fail if there is not a conversion from a given input to the selected type.</P ></LI ></OL ></DIV ><P >Some examples follow.</P ><DIV CLASS="EXAMPLE" ><A NAME="AEN25675" ></A ><P ><B >Example 10-10. Type Resolution with Underspecified Types in a Union</B ></P ><P ></P><PRE CLASS="SCREEN" >SELECT text 'a' AS "text" UNION SELECT 'b'; text ------ a b (2 rows)</PRE ><P> Here, the unknown-type literal <TT CLASS="LITERAL" >'b'</TT > will be resolved to type <TT CLASS="TYPE" >text</TT >.</P ></DIV ><DIV CLASS="EXAMPLE" ><A NAME="AEN25681" ></A ><P ><B >Example 10-11. Type Resolution in a Simple Union</B ></P ><P ></P><PRE CLASS="SCREEN" >SELECT 1.2 AS "numeric" UNION SELECT 1; numeric --------- 1 1.2 (2 rows)</PRE ><P> The literal <TT CLASS="LITERAL" >1.2</TT > is of type <TT CLASS="TYPE" >numeric</TT >, and the <TT CLASS="TYPE" >integer</TT > value <TT CLASS="LITERAL" >1</TT > can be cast implicitly to <TT CLASS="TYPE" >numeric</TT >, so that type is used.</P ></DIV ><DIV CLASS="EXAMPLE" ><A NAME="AEN25690" ></A ><P ><B >Example 10-12. Type Resolution in a Transposed Union</B ></P ><P ></P><PRE CLASS="SCREEN" >SELECT 1 AS "real" UNION SELECT CAST('2.2' AS REAL); real ------ 1 2.2 (2 rows)</PRE ><P> Here, since type <TT CLASS="TYPE" >real</TT > cannot be implicitly cast to <TT CLASS="TYPE" >integer</TT >, but <TT CLASS="TYPE" >integer</TT > can be implicitly cast to <TT CLASS="TYPE" >real</TT >, the union result type is resolved as <TT CLASS="TYPE" >real</TT >.</P ></DIV ><DIV CLASS="EXAMPLE" ><A NAME="AEN25699" ></A ><P ><B >Example 10-13. Type Resolution in a Nested Union</B ></P ><P ></P><PRE CLASS="SCREEN" >SELECT NULL UNION SELECT NULL UNION SELECT 1; ERROR: UNION types text and integer cannot be matched</PRE ><P> This failure occurs because <SPAN CLASS="PRODUCTNAME" >PostgreSQL</SPAN > treats multiple <TT CLASS="LITERAL" >UNION</TT >s as a nest of pairwise operations; that is, this input is the same as </P><PRE CLASS="SCREEN" >(SELECT NULL UNION SELECT NULL) UNION SELECT 1;</PRE ><P> The inner <TT CLASS="LITERAL" >UNION</TT > is resolved as emitting type <TT CLASS="TYPE" >text</TT >, according to the rules given above. Then the outer <TT CLASS="LITERAL" >UNION</TT > has inputs of types <TT CLASS="TYPE" >text</TT > and <TT CLASS="TYPE" >integer</TT >, leading to the observed error. The problem can be fixed by ensuring that the leftmost <TT CLASS="LITERAL" >UNION</TT > has at least one input of the desired result type.</P ><P ><TT CLASS="LITERAL" >INTERSECT</TT > and <TT CLASS="LITERAL" >EXCEPT</TT > operations are likewise resolved pairwise. However, the other constructs described in this section consider all of their inputs in one resolution step.</P ></DIV ></DIV ><H3 CLASS="FOOTNOTES" >Notes</H3 ><TABLE BORDER="0" CLASS="FOOTNOTES" WIDTH="100%" ><TR ><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="5%" ><A NAME="FTN.AEN25658" HREF="typeconv-union-case.html#AEN25658" ><SPAN CLASS="footnote" >[1]</SPAN ></A ></TD ><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="95%" ><P > Somewhat like the treatment of domain inputs for operators and functions, this behavior allows a domain type to be preserved through a <TT CLASS="LITERAL" >UNION</TT > or similar construct, so long as the user is careful to ensure that all inputs are implicitly or explicitly of that exact type. Otherwise the domain's base type will be preferred. </P ></TD ></TR ></TABLE ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="typeconv-query.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="index.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="indexes.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >Value Storage</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="typeconv.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >Indexes</TD ></TR ></TABLE ></DIV ></BODY ></HTML >