"David G. Johnston" writes:
> On Mon, Aug 17, 2020 at 10:11 AM Tom Lane wrote:
>> Yeah, me either. So here's a proposed patch, fixing a couple other
>> things:
> LGTM
Pushed, thanks for review.
regards, tom lane
On Mon, Aug 17, 2020 at 10:11 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Mon, Aug 17, 2020 at 8:31 AM Tom Lane wrote:
> >> 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'.
>
"David G. Johnston" writes:
> On Mon, Aug 17, 2020 at 8:31 AM Tom Lane wrote:
>> 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'.
Yeah, me either. So here's a proposed patch, fixing a couple
On Mon, Aug 17, 2020 at 8:31 AM Tom Lane wrote:
> "David G. Johnston" 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
"David G. Johnston" 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
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
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
"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
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
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.
10 matches
Mail list logo
