@atombrella what do you need / how can I help to get this over the finish line?

@MarkusH The biggest hurdle now is the unnecessary lookup casts. I posted a question on IRC about it, but perhaps the mailing list is a better place. On PostgreSQL, cast is a mutable function, and table.date_column >= '2007-10-01'::timestamp makes it break. I think I figured out the second thing in the list by adding params=None somewhere in AddIndex to the execute-call.

@felixxm Could you please assist with the Oracle test failures?

@atombrella Sure, I will check them in this week.

@atombrella Thanks for this PR 🚀 On Oracle we should be able to emulate (in most cases) partial indexes by function-based indexes. I will check how it works with this PR.

@felixxm Aren't function-based indexes what was attempted in #8056 ? I have a local branch trying to rework some of it, but I am stuck how to deal with the expression and columns in the DDL-classes that were introduced after that PR was made.

@atombrella Oracle doesn't index NULL values, therefore all indexes are partial indexes (it's not a 🐛 it's a feature 😄). Example SQL for the PartialIndexTests.test_partial_index:

CREATE INDEX "RECENT_ARTICLE_IDX" ON "INDEXES_ARTICLE" (
    CASE WHEN "PUB_DATE" > '2015-01-01' THEN 1 END
);

Awesome stuff!

Is handling of unique indexes planned for this feature? They can be really useful as a conditional alternative for unique constraints.

@georgebrock there's work being done in this regards in #10337.

Not sure about the API yet but I think the idea would be to have UniqueConstraint accept a condition=Q object as well and have it use a partial unique index under the hood #10271 (comment)

@felixxm Would you be ok with a note about Oracle? I don't think dealing with functional indexes is in the scope of this PR. Besides, since the predicate is an addition to the columns, I'm not sure how a potential rewrite would look like.

Likewise for unique-constraints; this seems to be handled currently in the ongoing UniqueConstraint PR. I think unique as an argument to Index was suggested in index-related PR discussions.

Likewise for unique-constraints; this seems to be handled currently in the ongoing UniqueConstraint PR. I think unique as an argument to Index was suggested in index-related PR discussions.

yeah we really need to gather consensus on the unique kwarg. Having both UniqueConstraint and Index(unique=True) feels odd to me. I'd prefer if only one of the two existed and I tend to agree with @Ian-Foote in #10271 (comment).

I'm happy to look into supporting partial unique constraints, building on top of work in this PR and #10337 (based on #10271), but I'd like to get the outstanding work merged first. Do we have a ticket for this?

After thinking about it a bit more I think there's room for both UniqueConstraint and Index(unique=True). With features such as PostgreSQL's 11 unique index INCLUDE and other tweaks unique indexes might require I feel like there should be a way to define both.

Maybe UniqueConstraint(index_name='foo') could be added later on or we could make Index(unique) register a unique constraint automatically? I'm not sure what's the best API here but having a way to reference unique constraints locally could definitely be useful with regards to API's such as bulk_create that could be augmented to express unique constraint conflict resolution.

e.g.

Appointment.objects.bulk_create(objs, conflict_updates=[
    ConflictUpdate(
        'location_timeslot',  # UniqueConstraint(name)
        Q(prefered_timeslot=False),
        timeslot=Subquery(
            Availability.objects.filter(
                location=OuterRef('location')
            ).values('timeslot').order_by('timeslot')[1]
        ),
    ],
})

ON CONFLICT UPDATE
    SET timeslot = (SELECT timeslot FROM ...) WHERE excluded.prefered_timeslot = false

or warn about get_or_create/update_or_create usage against a set of fields that aren't included in a unique constraint.