From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com> |
Subject: | Re: range bug in resolve_generic_type? |
Date: | 2019-08-27 15:23:32 |
Message-ID: | 12875.1566919412@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> writes:
> I was looking at resolve_generic_type to add anymultirange support,
> and the range logic doesn't seem correct to me.
Hmmm...
> resolve_generic_type(ANYARRAYOID, x, ANYRANGEOID) - this will return
> an array of the *range type*, but that contracts the normal
> relationship between anyelement and anyrange. It should return an
> array of the range's element type.
I seem to recall that we discussed this exact point during development
of the range feature, and concluded that this was the behavior we
wanted, ie, treat anyrange like a scalar for this purpose. Otherwise
there isn't any way to use a polymorphic function to build an array
of ranges, and that seemed more useful than being able to build
an array of the range elements. Jeff might remember more here.
> resolve_generic_type(ANYRANGEOID, x, ANYRANGEOID) - this will return
> the known range's *element* type, but it should return the known
> range.
Yeah, that seems like a flat-out bug.
> Fortunately we never call the function in either of those ways.
Wouldn't it depend on the signature+result type of the user-defined
function we're dealing with? (That is, calls with constant argument
types are probably not the interesting ones.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2019-08-27 15:26:49 | Re: pgbench - implement strict TPC-B benchmark |
Previous Message | Tom Lane | 2019-08-27 15:05:49 | Re: old_snapshot_threshold vs indexes |