We had a question about why an ARRAY[] construct was resolving the
array's type strangely [1]. The documentation about this [2] says
that the relevant resolution rules are:
5. Choose the first non-unknown input type which is a preferred type in
that category, if there is one.
6. Otherwise,
On Sun, Aug 16, 2020 at 2:26 PM Tom Lane wrote:
> We had a question about why an ARRAY[] construct was resolving the
> array's type strangely [1].
In this specific complaint it strikes me as undesirable to have an lossy
implicit cast from text to name - and if that wasn't present then text
woul
"David G. Johnston" writes:
> On Sun, Aug 16, 2020 at 2:26 PM Tom Lane wrote:
>> We had a question about why an ARRAY[] construct was resolving the
>> array's type strangely [1].
> In this specific complaint it strikes me as undesirable to have an lossy
> implicit cast from text to name - and if
On Sun, Aug 16, 2020 at 5:32 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Sun, Aug 16, 2020 at 2:26 PM Tom Lane wrote:
>
> > Seems like 5 and 6 need to be merged - the chosen type is the first one
> > that all subsequent types can be implicitly cast to. We do not guarantee
> > that
On Sun, Aug 16, 2020 at 5:58 PM David G. Johnston <
david.g.johns...@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 cho
