Re: range_agg - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: range_agg
Date
Msg-id CAFj8pRAaMrD0OcWmQfxQ_SN7ZMYOB_7Yak9Eb==KfMT6OMrttg@mail.gmail.com
Whole thread Raw
In response to Re: range_agg  (Paul A Jungwirth <pj@illuminatedcomputing.com>)
Responses Re: range_agg
List pgsql-hackers


pá 17. 1. 2020 v 21:08 odesílatel Paul A Jungwirth <pj@illuminatedcomputing.com> napsal:
On Fri, Jan 10, 2020 at 1:38 AM Pavel Stehule <pavel.stehule@gmail.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

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: backup manifests
Next
From: Alexander Korotkov
Date:
Subject: Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line