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: 2020-01-18 15:19:24
Message-ID: CAFj8pRAaMrD0OcWmQfxQ_SN7ZMYOB_7Yak9Eb==KfMT6OMrttg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

pá 17. 1. 2020 v 21:08 odesílatel Paul A Jungwirth <
pj(at)illuminatedcomputing(dot)com> napsal:

> On Fri, Jan 10, 2020 at 1:38 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >> This still leaves the question of how best to format the docs for
> >> these operators. I like being able to combine all the <@ variations
> >> (e.g.) into one table row, but if that is too ugly I could give them
> >> separate rows instead. Giving them all their own row consumes a lot of
> >> vertical space though, and to me that makes the docs more tedious to
> >> read & browse, so it's harder to grasp all the available range-related
> >> operations at a glance.
> >
> >
> > I have similar opinion - maybe is better do documentation for range and
> multirange separately. Sometimes there are still removed operators @+
>
> I like keeping the range/multirange operators together since they are
> so similar for both types, but if others disagree I'd be grateful for
> more feedback.
>

ok

>
> You're right that I left in a few references to the old @+ style
> operators in the examples; I've fixed those.
>
> > If you can share TYPTYPE_RANGE in code for multiranges, then it should
> be 'r'. If not, then it needs own value.
>
> Okay. I think a new 'm' value is warranted because they are not
> interchangeable.
>
> >> I experimented with setting pg_type.typelem to the multirange's range
> >> type, but it seemed to break a lot of things, and reading the code I
> >> saw some places that treat a non-zero typelem as synonymous with being
> >> an array. So I'm reluctant to make this change also, especially when
> >> it is just as easy to query pg_range to get a multirange's range type.
> >
> >
> > ok, it is unhappy, but it is true. This note should be somewhere in
> code, please
>
> I've added a comment about this. I put it at the top of DefineRange
> but let me know if that's the wrong place.
>
> The attached file is also rebased on currrent master.
>

Can be nice to have a polymorphic function

multirange(anymultirange, anyrange) returns anymultirange. This functions
should to do multirange from $2 to type $1

It can enhance to using polymorphic types and simplify casting.

Usage

CREATE OR REPLACE FUNCTION diff(anymultirange, anyrange)
RETURNS anymultirange AS $$
SELECT $1 - multirange($1, $2)
$$ LANGUAGE sql;

when I tried to write this function in plpgsql I got

create or replace function multirange(anymultirange, anyrange) returns
anymultirange as $$
begin
execute format('select $2::%I', pg_typeof($1)) into $1;
return $1;
end;
$$ language plpgsql immutable strict;

ERROR: unrecognized typtype: 109
CONTEXT: compilation of PL/pgSQL function "multirange" near line 1

So probably some support in PL is missing

But all others looks very well

Regards

Pavel

>
> Thanks!
> Paul
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2020-01-18 15:21:22 Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line
Previous Message Bruce Momjian 2020-01-18 14:36:14 Re: backup manifests