#36051: Declare arity on aggregate functions
-------------------------------------+-------------------------------------
     Reporter:  Jacob Walls          |                    Owner:  Jacob
                                     |  Walls
         Type:  New feature          |                   Status:  assigned
    Component:  Database layer       |                  Version:  dev
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  1
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):

 > Super helpful. I'll update #36042 to do as you describe here, and then
 we can refocus this ticket on adding arity checks to aggregates, since it
 sounds like we have consensus on that (and that doesn't have to land in
 5.2).

 That makes sense!

 > Certainly there is a difference between those two calls, but on the main
 branch the unpacking was already happening, i.e. Max(F("pk")) already
 compiles to Max(col1, col2), not Max((col1, col2))

 `Max("pk")` (we can drop the explicit `F`) compiles to `MAX(col1, col2)`
 at the SQL level due to the quirky way `ColPairs.as_sql` is implemented to
 support `SELECT` and `GROUP BY` references on backends that don't have
 native `ROW` / tuple support but it ''resolves'' to `Max(ColPairs("col1",
 "col2"))` which is a distinction that makes me believe we should not use
 `arity` and unpacking for this purpose.

 > Thanks for letting me kick the tires (this is helping me get more
 comfortable with the ORM internals!)

 Happy my feedback is useful, thanks for your time spent making the
 composite primary key usage experience better. The current awkwardness
 around `ColPairs.as_sql` and `Tuple` will vanish once we have proper
 support for composite fields but there might be a way to simplify things
 before that by getting rid of the the hacky way `SELECT` and `GROUP BY`
 deal with `ColPairs` compilation. I'll see if I can get something working
 tomorrow.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/36051#comment:5>
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 visit 
https://groups.google.com/d/msgid/django-updates/01070194350327af-ff4367fe-fff6-4997-8803-e5f0f8bd4fed-000000%40eu-central-1.amazonses.com.

Reply via email to