Re: Inaccurate description of UNION/CASE/etc type selection
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pg Docs <pgsql-docs@lists.postgresql.org>
Date: 2020-08-17T01:06:25Z
Lists: pgsql-docs
On Sun, Aug 16, 2020 at 5:58 PM David G. Johnston < david.g.johnston@gmail.com> wrote: > 5. If the first non-unknown type is a preferred type it is chosen, > otherwise it is made a candidate, and then, > 6. each subsequent type is compared to the current candidate, with a new > candidate being chosen only when there exists a non-mutal implicit cast to > the new type. > 6a. If at any point a preferred type is made a candidate then it will be > chosen. > More concisely: Make the first input type a candidate type. Each subsequent input type is compared to the current candidate, with a new candidate being chosen only when there exists a non-mutal implicit cast to the new type. If at any point a preferred type is made a candidate then it will be chosen. In my original the whole if/otherwise in 5 is pointless given the presence of 6a. David J.
Commits
-
Doc: fix description of UNION/CASE/etc type unification.
- fd55df04edb9 11.10 landed
- b88f6ad54ce6 9.5.24 landed
- 8216a1d3ed27 13.0 landed
- 722564cf0d7c 9.6.20 landed
- 59fb9ef15561 10.15 landed
- 314f65716c37 12.5 landed
- 22e75a341ecc 14.0 landed