Re: range_agg - Mailing list pgsql-hackers

From Paul A Jungwirth
Subject Re: range_agg
Date
Msg-id CA+renyXaiH6c7xyfSCtOu_3UU2qFvP17v4m9zAM7w-_UokeScg@mail.gmail.com
Whole thread Raw
In response to Re: range_agg  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: range_agg  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Fri, Dec 20, 2019 at 10:19 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I had a talk with Paul about possible simplification of designed operators. Last message from Paul was - he is
workingon new version.
 

Thanks Alvaro & Pavel for helping move this forward. I've added the
casts but they aren't used automatically for things like
`range_union(r, mr)` or `mr + r`, even though they are implicit.
That's because the casts are for concrete types (e.g. int4range ->
int4multirange) but the functions & operators are for polymorphic
types (anymultirange + anymultirange). So I'd like to get some
feedback about the best way to proceed.

Is it permitted to add casts with polymorphic inputs & outputs? Is
that something that we would actually want to do? I'd probably need
both the polymorphic and concrete casts so that you could still say
`int4range(1,2)::int4multirange`.

Should I change the coerce code to look for casts among concrete types
when the function has polymorphic types? I'm pretty scared to do
something like that though, both because of the complexity and lest I
cause unintended effects.

Should I just give up on implicit casts and require you to specify
one? That makes it a little more annoying to mix range & multirange
types, but personally I'm okay with that. This is my preferred
approach.

I have some time over the holidays to work on the other changes Alvaro
has suggested.

Thanks,
Paul



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: range_agg
Next
From: Alvaro Herrera
Date:
Subject: Re: range_agg