Context Navigation

Changes between Initial Version and Version 1 of Ticket #35586, comment 3

initial	v1
1		This one is tricky, the ORM and its aggregation logic was not built in a way that accounts for annotations spawning rows themselves (instead of through `JOIN`s) like some [https://www.postgresql.org/docs/current/functions-srf.html Postgres set-returning functions] (e.g. `UNNEST`). These do effectively throw a wrench in the optimization introduced in 4.2 if the set-returning annotation is not referenced by the aggregation.
	1	This one is tricky, the ORM and its aggregation logic was not built in a way that accounts for annotations spawning rows themselves (instead of through `JOIN`s) like some [https://www.postgresql.org/docs/current/functions-srf.html Postgres set-returning functions] (e.g. `UNNEST`). These do effectively throw a wrench in the optimization introduced in 4.2 (see #28477) if the set-returning annotation is not referenced by the aggregation.
2	2
3	3	What is really needed here is likely a `Expression.set_returning: bool = False` attribute that the ORM can consider to enforce the subquery pushdown and preventing of annotation eliding.