#34078: Should the Postgres range_merge aggregate be added to postgres.contrib?
-------------------------------------+-------------------------------------
               Reporter:  Jack       |          Owner:  (none)
  Linke                              |
                   Type:  New        |         Status:  new
  feature                            |
              Component:             |        Version:  4.1
  contrib.postgres                   |       Keywords:  postgres range
               Severity:  Normal     |  range_merge aggregation aggregate
           Triage Stage:             |      Has patch:  0
  Unreviewed                         |
    Needs documentation:  0          |    Needs tests:  0
Patch needs improvement:  0          |  Easy pickings:  0
                  UI/UX:  0          |
-------------------------------------+-------------------------------------
 Most of the Postgres range functions have been exposed for querying in
 django, but not the {{{range_merge}}} Aggregate function.

 As background, {{{range_merge}}} "Computes the smallest range that
 includes ... the given ranges".

 The existing Postgres functions exposed for queries in django:
 https://docs.djangoproject.com/en/4.1/ref/contrib/postgres/fields
 /#querying-using-the-bounds

 The full list of Posgres range functions (note that range_merge is the
 only one not represented in django): https://www.postgresql.org/docs/14
 /functions-range.html#RANGE-FUNCTIONS-TABLE

 ----

 To make use of this aggregation in my own project, I created a django
 package that runs a migration to CREATE (or DROP) the aggregate function
 in the database (https://pypi.org/project/django-range-merge/).


 {{{
 operations = [
     migrations.RunSQL(
         sql=[("CREATE OR REPLACE AGGREGATE
 range_merge(anyrange)(sfunc=range_merge, stype=anyrange);")],
         reverse_sql=[("DROP AGGREGATE IF EXISTS range_merge(anyrange);")],
     )
 ]
 }}}


 Then, given the model:

 {{{
 class Event(models.Model):
     name = models.CharField(max_length=30)
     potential_visitors = models.IntegerRangeField()
 }}}

 And a few model instances:

 {{{
 {"id" : 1, "name" : "Birthday", "potential_visitors" : "[2, 3)"}
 {"id" : 2, "name" : "Bake Sale", "potential_visitors" : "[30, 50)"}
 {"id" : 3, "name" : "Band Camp", "potential_visitors" : "[22, 28)"}
 {"id" : 4, "name" : "Cooking Show", "potential_visitors" : "[7, 20)"}
 {"id" : 5, "name" : "Pajama Day", "potential_visitors" : "[15, 30)"}
 }}}

 Executing the query:

 {{{
 Event.objects.all().aggregate(
     output=Aggregate(F("potential_visitors"), function="range_merge")
 )
 }}}

 Returns:

 {{{{'output': NumericRange(2, 50, '[)')}}}}

 ----

 It looks like RunSQL is not used anywhere in django's codebase, except in
 tests, so I am not sure if adding this to the contrib.postgres codebase
 would be welcomed.

 Should this be added to django, or should it remain as a package separate
 from django itself?

-- 
Ticket URL: <https://code.djangoproject.com/ticket/34078>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070183bb857284-c88db069-3152-4296-a589-0543d7c694c3-000000%40eu-central-1.amazonses.com.

Reply via email to