On Tue, Aug 27, 2019 at 8:23 AM Tom Lane <t...@sss.pgh.pa.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
