Re: range_agg

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Paul A Jungwirth <pj(at)illuminatedcomputing(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 09:06:01
Message-ID: CAFj8pRAUso-5-+f-q-nword4F=QZOZuJaKdaqH_y_Ybom+fYsg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

st 20. 11. 2019 v 20:32 odesílatel Paul A Jungwirth <
pj(at)illuminatedcomputing(dot)com> napsal:

> On Tue, Nov 19, 2019 at 9:49 PM Paul A Jungwirth
> <pj(at)illuminatedcomputing(dot)com> wrote:
> >
> > On Tue, Nov 19, 2019 at 1:17 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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;
^
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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2019-11-21 09:15:34 Re: [HACKERS] Block level parallel vacuum
Previous Message Jeevan Chalke 2019-11-21 09:03:05 Re: backup manifests