Re: Inaccurate description of UNION/CASE/etc type selection

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Inaccurate description of UNION/CASE/etc type selection
Дата
Msg-id CAKFQuwYjvVgyw5Ehw8JnPPZ1Tjox_yxktdkw5U8gm8nSM=ejJQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Inaccurate description of UNION/CASE/etc type selection  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Inaccurate description of UNION/CASE/etc type selection  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-docs
On Mon, Aug 17, 2020 at 8:31 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> 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.

So this is just a verbatim statement of the algorithm, which is what
I was hoping to avoid :-(.  But maybe there's no simpler way.


I got nothin'.  The locking onto the preferred type is conditional on one being chosen and there doesn't seem to be any greater principle that emerges from the pairwise matching algorithm - at least given that implicit casts are essentially randomly distributed and the algorithm is order-dependent.

David J.


В списке pgsql-docs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Inaccurate description of UNION/CASE/etc type selection
Следующее
От: Bruce Momjian
Дата:
Сообщение: "stable storage"