On Mon, May 6, 2019 at 4:21 PM Paul Jungwirth <p...@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
range_agg_v1.patch
Description: Binary data