Re: anyelement -> anyrange

On 8/16/16 6:56 PM, David G. Johnston wrote:
> On Tue, Aug 16, 2016 at 7:47 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com
> <mailto:Jim(dot)Nasby(at)bluetreble(dot)com>>wrote:
>
> On 8/15/16 10:12 PM, Tom Lane wrote:
>
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
>
> Any reason why we can create a function that accepts
> anyelement and
> returns anyarray, but can't do the same with anyrange?
>
>
> Because there can be more than one range type over the same element
> type, so we couldn't deduce which one should be used for anyrange.
>
> The other direction (inferring anyelement from anyrange) does work.
>
>
> Is there an actual use case for that? I'm not seeing what it would be...
>
>
> ​https://www.postgresql.org/docs/9.5/static/functions-range.html
>
> lower() and upper() both use it.

Nothing built in uses what Tom mentioned: having multiple *range types*
for a single base type. lower() and upper() use *anyrange*, which is a
completely different animal.

I can't think of any reason you'd want two different range types on a
single element type. If we made that a constraint, we could resolve an
anyrange from an anyelement. That would be very useful in some cases
(one example being the range_from_array() functions I just created).

BTW, another option would be to allow marking a specific range type as
being "primary", so if you did need to define some other variation on
int4range you could do so, but you'd have to decide whether it or
int4range was the primary one that anyelement->anyrange would use.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461