Re: range_agg

> 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@illuminatedcomputing.com