Re: range_agg

From: Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: range_agg
Date: 2019-05-06 23:21:45
Message-ID: ab15963e-8827-2760-f415-f22f6e404c2a@illuminatedcomputing.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I suspect that if you build it, the will come, "they" being anyone who
> has to schedule coverage, check usage of a resource over time, etc. Is
> this something you want help with at some level? Coding, testing,
> promoting...

You might be right. :-) Most of this is done already, since it was
largely copy/paste from my extension plus figuring out how to register
built-in functions with the .dat files. I need to write some docs and do
some cleanup and I'll have a CF entry. And I'll probably go ahead and
add your two suggestions too.... Things I'd love help with:

- Getting more opinions about the functions' interface, either from you
or others, especially:
- In the extension I have a boolean param to let you accept gaps or
raise an error, and another for overlaps. But what about
accepting/raising/returning null? How should the parameters expose that?
Maybe leave them as bools but accept true/false/null for
permit/raise/nullify respectively? That seems like a questionable UI,
but I'm not sure what would be better. Maybe someone with better taste
can weigh in. :-) I tried to find existing built-in functions that gave
a enumeration of options like that but couldn't find an existing example.
- Also: what do you think of the question I asked in my reply to
Corey? Is it better to have *all* range_agg functions return an array of
ranges, or it is nicer to have a variant that always returns a single range?
- Getting it reviewed.
- Advice about sequencing it with respect to my temporal foreign keys
patch, where I'm planning to call range_agg to check an FK. E.g. should
my FK patch be a diff on top of the range_agg code? I assume they should
have separate CF entries though?

Oh and here's something specific:

- I gave oids to my new functions starting with 8000, because I thought
I saw some discussion about that recently, and the final committer will
correct the oids to the current n+1? But I can't find that discussion
anymore, so if that's the wrong approach let me know.

Thanks!

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2019-05-07 00:15:30 Re: _bt_split(), and the risk of OOM before its critical section
Previous Message Peter Geoghegan 2019-05-06 23:11:55 Re: _bt_split(), and the risk of OOM before its critical section