diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-08-17 15:40:07 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-08-17 15:40:07 -0400 |
| commit | 314f65716c37d515979eb2f06430b18bb7a09a0d (patch) | |
| tree | 551486be67e88ce7f2e5816483f68eb5d0ea542a | |
| parent | 9f44d71b06b0d457ad3e5d7fdcbba2039f3000ef (diff) | |
| download | postgresql-314f65716c37d515979eb2f06430b18bb7a09a0d.tar.gz postgresql-314f65716c37d515979eb2f06430b18bb7a09a0d.zip | |
Doc: fix description of UNION/CASE/etc type unification.
The description of what select_common_type() does was not terribly
accurate. Improve it.
David Johnston and Tom Lane
Discussion: https://postgr.es/m/1019930.1597613200@sss.pgh.pa.us
| -rw-r--r-- | doc/src/sgml/typeconv.sgml | 33 |
1 files changed, 19 insertions, 14 deletions
diff --git a/doc/src/sgml/typeconv.sgml b/doc/src/sgml/typeconv.sgml index 81dba7dacfe..8900d0eb383 100644 --- a/doc/src/sgml/typeconv.sgml +++ b/doc/src/sgml/typeconv.sgml @@ -1069,7 +1069,7 @@ domain's base type for all subsequent steps. functions, this behavior allows a domain type to be preserved through a <literal>UNION</literal> 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. + exact type. Otherwise the domain's base type will be used. </para> </footnote> </para> @@ -1092,24 +1092,29 @@ If the non-unknown inputs are not all of the same type category, fail. <step performance="required"> <para> -Choose the first non-unknown input type which is a preferred type in -that category, if there is one. -</para> -</step> - -<step performance="required"> -<para> -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.) +Select the first non-unknown input type as the candidate type, +then consider each other non-unknown input type, left to right. + <footnote> + <para> + For historical reasons, <literal>CASE</literal> treats + its <literal>ELSE</literal> clause (if any) as the <quote>first</quote> + input, with the <literal>THEN</literal> clauses(s) considered after + that. In all other cases, <quote>left to right</quote> means the order + in which the expressions appear in the query text. + </para> + </footnote> +If the candidate type can be implicitly converted to the other type, +but not vice-versa, select the other type as the new candidate type. +Then continue considering the remaining inputs. If, at any stage of this +process, a preferred type is selected, stop considering additional +inputs. </para> </step> <step performance="required"> <para> -Convert all inputs to the selected type. Fail if there is not a -conversion from a given input to the selected type. +Convert all inputs to the final candidate type. Fail if there is not an +implicit conversion from a given input type to the candidate type. </para> </step> </procedure> |