| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Inaccurate description of UNION/CASE/etc type selection |
| Date: | 2020-08-17 01:06:25 |
| Message-ID: | CAKFQuwY_TRhxKvnf26L0ZQpYm56Y7__WL7GhR0VGg8AX90HTJw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs |
On Sun, Aug 16, 2020 at 5:58 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-08-17 15:31:04 | Re: Inaccurate description of UNION/CASE/etc type selection |
| Previous Message | David G. Johnston | 2020-08-17 00:58:00 | Re: Inaccurate description of UNION/CASE/etc type selection |