Re: range_agg with multirange inputs

From: Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: range_agg with multirange inputs
Date: 2022-03-12 03:18:50
Message-ID: 71eabe81-3e69-0476-347a-c8342de5cd41@illuminatedcomputing.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/10/22 14:07, Chapman Flack wrote:
> When I apply this patch, I get a func.sgml with two entries for
> range_intersect_agg(anymultirange).

Arg, fixed.

> In range_agg_transfn, you've changed the message in the "must be called
> with a range or multirange"; that seems like another good candidate to
> be an elog.

Agreed. Updated here.

> I think your query finds aggregate declarations that share the same SQL
> function declaration as their finalizer functions. That seems to be more
> common.
>
> The query I used looks for cases where different SQL-declared functions
> appear as finalizers of aggregates, but the different SQL declared functions
> share the same internal C implementation.

Okay, I see. I believe that is quite common for ordinary SQL functions.
Sharing a prosrc seems even less remarkable than sharing an aggfinalfn.
You're right there are no cases for other finalfns yet, but I don't
think there is anything special about finalfns that would make this a
weirder thing to do there than with ordinary functions. Still, noting it
with a comment does seem helpful. I've updated the remark to match what
you suggested.

Thank you again for the review, and sorry for so many iterations! :-)

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com

Attachment Content-Type Size
v4-0001-Add-range_agg-with-multirange-inputs.patch text/x-patch 14.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2022-03-12 03:24:12 Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Previous Message Amit Kapila 2022-03-12 02:58:35 Re: Issue with pg_stat_subscription_stats