Changes between Initial Version and Version 1 of Ticket #28477, comment 23
- Timestamp:
- Jul 5, 2023, 10:47:02 PM (17 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28477, comment 23
initial v1 1 1 Dustin, [https://forum.djangoproject.com/t/django-4-2-behavior-change-when-using-arrayagg-on-unnested-arrayfield-postgresql-specific/21547/2 I think this answer is your way out]. 2 2 3 Basically the optimization should be disabled for any set-returning function but since Django only has single native one,`Subquery`, so the optimization is only disabledwhen the `subquery = True` attribute is set.3 Basically the optimization should be disabled for any set-returning function but since Django only has single native one,`Subquery`, the optimization is only disabled through duck typing when the `subquery = True` attribute is set. 4 4 5 5 In order to truly solve this issue I think we should introduce a new documented `Expression.set_returning: bool` (better name welcome!) flag that defaults to `False` but is set to `True` for `Subquery`. 6 6 7 The root of this problem is that the ORM simply doesn't support functions that return rows in a generic way . Instead it branches out using `getattr(expr, "subquery", False)` in all cases that it makes the most sense to support them (e.g. `__in` looups).7 The root of this problem is that the ORM simply doesn't support functions that return rows in a generic way (your assignment of `output_field=JSONField()` is wrong but there's no way to say `output_field=Set(JSONField())`). Instead it branches out using `getattr(expr, "subquery", False)` in all cases that it makes the most sense to support them (e.g. `__in` looups).