Re: range bug in resolve_generic_type?

On Tue, Aug 27, 2019 at 8:23 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > 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

Well, I don't think that works anyway. At least I couldn't get it to
work here: https://www.postgresql.org/message-id/CA%2BrenyVOjb4xQZGjdCnA54-1nzVSY%2B47-h4nkM-EP5J%3D1z%3Db9w%40mail.gmail.com

But also check_generic_type_consistency works the way I'm saying:

- if anyrange = r then anyelement = elemOf(r)
- if anyarray = a then anyelement = elemOf(a)
- elemOf(r) = elemOf(a)

So resolve_generic_type should agree with that, right?

Also, I'm interested in adding not just anymultirange but also
anyrangearray, which *would* let you have polymorphic
arrays-of-ranges. (I thought I would need anyrangearray for a
multirange constructor, but actually now I think I might not need
it---maybe. But still it seems like a helpful thing.)

> > 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.)

I suppose an extension could call it (although it seems unlikely). But
I couldn't find anywhere in the Postgres code that doesn't call it
with hardcoded arguments. (I certainly could have missed something
though.)

Thanks!
Paul