Re: range_agg - Mailing list pgsql-hackers

From Paul Jungwirth
Subject Re: range_agg
Date
Msg-id 5b52f2f4-a0ec-76b1-8a73-98b8a7270bd6@illuminatedcomputing.com
Whole thread Raw
In response to Re: range_agg  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: range_agg  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On 11/21/19 1:06 AM, Pavel Stehule wrote:
> 2. I don't like introduction "safe" operators - now the basic operators 
> are doubled, and nobody without documentation will use @* operators.
> 
> It is not intuitive. I think is better to map this functionality to 
> basic operators +- * and implement it just for pairs (Multirange, 
> Multirange) and (Multirange, Range) if it is possible
> 
> It's same relation line Numeric X integer. There should not be 
> introduced new operators. If somebody need it for ranges, then he can 
> use cast to multirange, and can continue.
 > [snip]
> 3. There are not prepared casts -
> 
> postgres=# select int8range(10,15)::int8multirange;
> ERROR:  cannot cast type int8range to int8multirange
> LINE 1: select int8range(10,15)::int8multirange;
>                                 ^
> There should be some a) fully generic solution, or b) possibility to 
> build implicit cast when any multirange type is created.

Okay, I like the idea of just having `range + range` and `multirange + 
multirange`, then letting you cast between ranges and multiranges. The 
analogy to int/numeric seems strong. I guess if you cast a multirange 
with more than one element to a range it will raise an error. That will 
let me clean up the docs a lot too.

Thanks!

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why overhead of SPI is so large?
Next
From: Thomas Munro
Date:
Subject: Re: Copyright information in source files