On Sun, Jan 19, 2020 at 9:57 PM Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:
> On Sun, Jan 19, 2020 at 4:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > True for casts involving concrete types, mainly because we'd like
> > the identity "value::typename == typename(value)" to hold without
> > too much worry about whether the latter is a plain function call
> > or a special case. Not sure whether it makes as much sense for
> > polymorphics, since casting to a polymorphic type is pretty silly:
> > we do seem to allow you to do that, but it's a no-op.
> >
> > ...
> >
> > Alternatively, consider this: a cast from some concrete multirange type
> > to anymultirange is a no-op, while any other sort of cast probably ought
> > to be casting to some particular concrete multirange type. That would
> > line up with the existing operations for plain ranges.
>
> I agree you wouldn't actually cast by saying x::anymultirange, and the
> casts we define are already concrete, so instead you'd say
> x::int4multirange. But I think having a polymorphic function to
> convert from an anyrange to an anymultirange is useful so you can
> write generic functions. I can see how calling it "anymultirange" may
> be preferring the implementor perspective over the user perspective
> though, and how simply "multirange" would be more empathetic. I don't
> mind taking that approach.
Here is a patch with anymultirange(anyrange) renamed to
multirange(anyrange). I also rebased on the latest master, added
documentation about the multirange(anyrange) function, and slightly
adjusted the formatting of the range functions table.
Thanks,
Paul