From: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: range_agg |
Date: | 2019-11-21 20:15:28 |
Message-ID: | 5b52f2f4-a0ec-76b1-8a73-98b8a7270bd6@illuminatedcomputing.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)illuminatedcomputing(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-11-21 20:28:44 | Re: Copyright information in source files |
Previous Message | Tom Lane | 2019-11-21 19:44:37 | Re: Why overhead of SPI is so large? |