On Mon, May 6, 2019 at 4:21 PM Paul Jungwirth
<pj@illuminatedcomputing.com> wrote:
> I need to write some docs and do
> some cleanup and I'll have a CF entry.
Here is an initial patch. I'd love to have some feedback! :-)
One challenge was handling polymorphism, since I want to have this:
anyrange[] range_agg(anyrange, bool, bool)
But there is no anyrange[]. I asked about this back when I wrote my
extension too:
https://www.postgresql.org/message-id/CA%2BrenyVOjb4xQZGjdCnA54-1nzVSY%2B47-h4nkM-EP5J%3D1z%3Db9w%40mail.gmail.com
Like then, I handled it by overloading the function with separate
signatures for each built-in range type:
int4range[] range_agg(int4range, bool, bool);
int8range[] range_agg(int8range, bool, bool);
numrange[] range_agg(numrange, bool, bool);
tsrange[] range_agg(tsrange, bool, bool);
tstzrange[] range_agg(tstzrange, bool, bool);
daterange[] range_agg(daterange, bool, bool);
(And users can still define a range_agg for their own custom range
types using similar instructions to those in my extension's README.)
The problem was the opr_sanity regression test, which rejects
functions that share the same C-function implementation (roughly). I
took a few stabs at changing my code to pass that test, e.g. defining
separate wrapper functions for everything like this:
Datum
int4range_agg_transfn(PG_FUNCTION_ARGS) {
return range_agg_transfn(fcinfo);
}
But that felt like it was getting ridiculous (8 range types *
transfn+finalfn * 1-bool and 2-bool variants), so in the end I just
added my functions to the "permitted" output in opr_sanity. Let me
know if I should avoid that though.
Also I would still appreciate some bikeshedding over the functions' UI
since I don't feel great about it.
If the overall approach seems okay, I'm still open to adding David's
suggestions for weighted_range_agg and covering_range_agg.
Thanks!
Paul