Re: range_agg - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: range_agg |
| Date | |
| Msg-id | CAFj8pRAUso-5-+f-q-nword4F=QZOZuJaKdaqH_y_Ybom+fYsg@mail.gmail.com Whole thread Raw |
| In response to | Re: range_agg (Paul A Jungwirth <pj@illuminatedcomputing.com>) |
| Responses |
Re: range_agg
(Paul Jungwirth <pj@illuminatedcomputing.com>)
|
| List | pgsql-hackers |
st 20. 11. 2019 v 20:32 odesílatel Paul A Jungwirth <pj@illuminatedcomputing.com> napsal:
On Tue, Nov 19, 2019 at 9:49 PM Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:
>
> On Tue, Nov 19, 2019 at 1:17 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > Hi
> > I tested last patches. I found some issues
>
> Thank you for the review!
Here is an updated patch series fixing the problems from that last
review. I would still like some direction about the doc formatting:
yes, these bugs are fixed
there are not compilation's issues
tests passed
doc is ok
I have notes
1. the chapter should be renamed to "Range Functions and Operators" to "Range and Multirange Functions and Operators"
But now the doc is not well readable - there is not clean, what functions are for range type, what for multirange and what for both
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.
The "safe" operators can be implement on user space - but should not be default solution.
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;
^
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.
Regards
Pavel
> > I am not sure how much is correct to use <literallayout class="monospaced"> in doc. It is used for ranges, and multiranges, but no in other places
>
> I could use some advice here. Many operators seem best presented in
> groups of four, where only their parameter types change, for example:
>
> int8range < int8range
> int8range < int8multirange
> int8multirange < int8range
> int8multirange < int8multirange
>
> All I really want is to show those separated by line breaks. I
> couldn't find any other examples of that happening inside a table cell
> though (i.e. inside <row><entry></entry></row>). What is the best way
> to do that?
Personally I think it should be cleaned. Mainly if there is not visible differences. But range related doc it uses, so it is consistent with it. And then this is not big issue.
Thanks,
Paul
pgsql-hackers by date: