UNION, CASE, and Related Constructs
SQL UNION 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 INTERSECT and EXCEPT construct resolve dissimilar types in the same way as UNION. The CASE, ARRAY, VALUES, GREATEST and LEAST constructs use the identical algorithm to match up their component expressions and select a result data type.
Type Resolution for UNION, CASE, and Related Constructs
- If all inputs are of the same type, and it is not unknown, resolve as that type.
- If all inputs are of type unknown, resolve as type text (the preferred type of the string category). Otherwise, unknown inputs are ignored.
- If the inputs are not all of the same type category, a failure will be resulted. (Type unknown is not included in this case.)
- If the inputs are all of the same type category, choose the top preferred type in that category. (Exception: The UNION operation regards the type of the first branch as the selected type.)
typcategory in the pg_type system catalog indicates the data type category. typispreferred indicates whether a type is preferred in typcategory.
- Convert all inputs to the selected type. (Retain the original lengths of strings). Fail if there is not an implicit conversion from a given input to the selected type.
- If the input contains the json, txid_snapshot, sys_refcursor, or geometry type, UNION cannot be performed.
Type Resolution for CASE and COALESCE in TD Compatibility Type
- If all inputs are of the same type, and it is not unknown, resolve as that type.
- If all inputs are of type unknown, resolve as type text.
- If inputs are of the string type (including unknown which is resolved as type text) and digit type, resolve as the string type. If the inputs are not of the two types, an error will be reported.
- If the inputs are all of the same type category, choose the top preferred type in that category.
- Convert all inputs to the selected type. Fail if there is not an implicit conversion from a given input to the selected type.
Type Resolution for CASE in ORA Compatibility Type
decode(expr, search1, result1, search2, result2, ..., defresult): When the sql_beta_feature is set to a_style_coerce, the final return value type of the expression is set to the data type of result1 or a higher-precision data type in the same type as result1. (For example, numeric and int are both numeric data types, but numeric has higher precision and priority than int.) For CASE WHEN, the behavior is the same as the default behavior in ORA-compatible mode.
- If all inputs are of the same type, and it is not unknown, resolve as that type. Otherwise, proceed to the next step.
- Set the data type of result1 to the final return value type preferType, which belongs to preferCategory.
- Consider the data types of result2, result3, and defresult in sequence. If the type category is also preferCategory, which is the same as that of result1, check whether the precision (priority) is higher than that of preferType. If it is, update preferType to a data type with a higher precision. If the type category is not preferCategory, check whether the category can be implicitly converted to preferType. If it cannot, an error is reported.
- Uses the data type recorded by preferType as the return value type of the expression. The expression result is implicitly converted to this data type.
Note:
There is a special case where the character type of a super-large number is converted to the numeric type, for example, select decode(1, 2, 2, '53465465676465454657567678676'), in which the large number exceeds the range of the bigint and double types. If result1 is of the numeric type and does not meet the condition that all inputs are of the same type, the type of the return value is set to numeric to be compatible with this special case.
Note 2:
Priority of the numeric types: numeric > float8 > float4 > int8 > int4 > int2 > int1
Priority of the character types: text > varchar = nvarchar2 > bpchar > char
Priority of date types: timestamptz > timestamp > smalldatetime > date > abstime > timetz > time
Priority of date span types: interval > tinterval > reltime.
Note 3:
The following figure shows the supported implicit type conversion when set sql_beta_feature is set to 'a_style_coerce' in ORA compatibility mode. \ indicates that conversion is not required, yes indicates that conversion is supported, and the blank value indicates that conversion is not supported.
Examples
Example 1: Use type resolution with underspecified types in a union as the first example. Here, the unknown-type literal 'b' will be resolved to type text.
1 2 3 4 5 6 |
openGauss=# SELECT text 'a' AS "text" UNION SELECT 'b'; text ------ a b (2 rows) |
Example 2: Use type resolution in a simple union as the second example. The literal 1.2 is of type numeric, and the integer value 1 can be cast implicitly to numeric, so that type is used.
1 2 3 4 5 6 |
openGauss=# SELECT 1.2 AS "numeric" UNION SELECT 1; numeric --------- 1 1.2 (2 rows) |
Example 3: Use type resolution in a transposed union as the third example. Since type real cannot be implicitly cast to integer, but integer can be implicitly cast to real, the union result type is resolved as real.
1 2 3 4 5 6 |
openGauss=# SELECT 1 AS "real" UNION SELECT CAST('2.2' AS REAL); real ------ 1 2.2 (2 rows) |
Example 4: In the TD type, if input parameters for COALESCE are of int and varchar types, resolve as type varchar. In the A type, an error is reported.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
-- In the A type, create the a_1 database compatible with A. openGauss=# CREATE DATABASE a_1 dbcompatibility = 'A'; -- Switch to the a_1 database. openGauss=# \c a_1 -- Create the t1 table. a_1=# CREATE TABLE t1(a int, b varchar(10)); -- Show the execution plan of a statement for querying the types int and varchar of input parameters for COALESCE. a_1=# EXPLAIN SELECT coalesce(a, b) FROM t1; ERROR: COALESCE types integer and character varying cannot be matched LINE 1: EXPLAIN SELECT coalesce(a, b) FROM t1; ^ CONTEXT: referenced column: coalesce -- Delete the table. a_1=# DROP TABLE t1; -- Switch to openGauss. a_1=# \c openGauss -- In the TD type, create the td_1 database compatible with Teradata. openGauss=# CREATE DATABASE td_1 dbcompatibility = 'C'; -- Switch to the td_1 database. openGauss=# \c td_1 -- Create the t2 table. td_1=# CREATE TABLE t2(a int, b varchar(10)); -- Show the execution plan of a statement for querying the types int and varchar of input parameters for COALESCE. td_1=# EXPLAIN VERBOSE select coalesce(a, b) from t2; QUERY PLAN --------------------------------------------------------------------------------------- Data Node Scan (cost=0.00..0.00 rows=0 width=0) Output: (COALESCE((t2.a)::character varying, t2.b)) Node/s: All dbnodes Remote query: SELECT COALESCE(a::character varying, b) AS "coalesce" FROM public.t2 (4 rows) -- Delete the table. td_1=# DROP TABLE t2; -- Switch to openGauss. td_1=# \c openGauss -- Delete databases in A and TD types. openGauss=# DROP DATABASE a_1; openGauss=# DROP DATABASE td_1; |
Example 5: In ORA mode, set the final return value type of the expression to the data type of result1 or a higher-precision data type whose category is the same as that of the data type of result1.
-- In the ORA type, create the ora_1 database compatible with ORA. openGauss=# CREATE DATABASE ora_1 dbcompatibility = 'A'; -- Switch to the ora_1 database. openGauss=# \c ora_1 -- Enable the decode compatibility parameters. set sql_beta_feature='a_style_coerce'; -- Create the t1 table. ora_1=# CREATE TABLE t1(c_int int, c_float8 float8, c_char char(10), c_text text, c_date date); -- Insert data. ora_1=# INSERT INTO t1 VALUES(1, 2, '3', '4', date '12-10-2010'); -- The data type of result1 is char and that of defresult is text. The precision of text is higher, and the type of the return value is changed to text from char. ora_1=# SELECT decode(1, 2, c_char, c_text) AS result, pg_typeof(result) FROM t1; result | pg_typeof --------+----------- 4 | text (1 row) -- The data type of result1 is int, which is a numeric type. The type of the return value is set to numeric. ora_1=# SELECT decode(1, 2, c_int, c_float8) AS result, pg_typeof(result) FROM t1; result | pg_typeof --------+----------- 2 | numeric (1 row) -- The implicit conversion from the data type of defresult to that of result1 does not exist. An error is reported. ora_1=# SELECT decode(1, 2, c_int, c_date) FROM t1; ERROR: CASE types integer and timestamp without time zone cannot be matched LINE 1: SELECT decode(1, 2, c_int, c_date) FROM t1; ^ CONTEXT: referenced column: c_date -- Disable the decode compatibility parameters. set sql_beta_feature='none'; -- Delete the table. ora_1=# DROP TABLE t1; DROP TABLE -- Switch to the postgres database: ora_1=# \c postgres -- Delete the database in ORA mode. openGauss=# DROP DATABASE ora_1; DROP DATABASE
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot