Deletion using subqueries doesn't work for aggregates, extra or select_related

[Anssi Kääriäinen]

Aggregates, extra and select_related add columns to the subselect. However, the subselect must contain only one column.

Example case (modified from #18676's example):

class OrgUnit(models.Model):
    name = models.CharField(max_length=64, unique=True)
    
class Login(models.Model):
    description = models.CharField(max_length=32)
    orgunit = models.ForeignKey(OrgUnit)

Login.objects.extra(
    select={'foo':'description'}
).annotate(
    n=models.Count('description')
).filter(n=1).select_related('orgunit').delete()

The above fails with "too many columns in subquery" for various databases.

I have a work-in-progress patch for this at: ​https://github.com/akaariai/django/commit/34a39ba8981638db2eb3fdb3d8d45393130a9d99

This is a regression caused by #18676, so marking as release blocker.

[Anssi Kääriäinen]

Updated patch at ​https://github.com/akaariai/django/compare/ticket_18676_fix

[Anssi Kääriäinen <akaariai@…>]

In f64a5ef404cb6fd28e008a01039a3beea2fa8e1b:

Fixed #19102 -- Fixed fast-path delete for modified SELECT clause cases

There was a bug introduced in #18676 which caused fast-path deletes
implemented as "DELETE WHERE pk IN <subquery>" to fail if the SELECT
clause contained additional stuff (for example extra() and annotate()).

Thanks to Trac alias pressureman for spotting this regression.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 4e8ecf0:

Refs #19102 -- Removed flaky test Ticket19102Tests.test_ticket_19102_distinct_on.

The subquery pushdown only happens because another table is involved in
filter. It's not the distinct usage that causes the pushdown.

The distinct('description').order_by('pk') expression is not valid
because SELECT DISTINCT ON must match initial ORDER BY expressions
which is not the case here.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 98ce39b5:

[3.2.x] Refs #19102 -- Removed flaky test Ticket19102Tests.test_ticket_19102_distinct_on.

The subquery pushdown only happens because another table is involved in
filter. It's not the distinct usage that causes the pushdown.

The distinct('description').order_by('pk') expression is not valid
because SELECT DISTINCT ON must match initial ORDER BY expressions
which is not the case here.

Backport of 4e8ecf0cb6ea36c45edb9cb86f0d63224e08097e from master