[Django] #34729: Add explicit option to enable IF EXISTS / IF NOT EXISTS in PostgresQL index operations

[Django]

#34729: Add explicit option to enable IF EXISTS / IF NOT EXISTS in PostgresQL index
operations
--------------------------------------------+------------------------
Reporter: Laurent Tramoy | Owner: (none)
Type: New feature | Status: new
Component: contrib.postgres | Version: 4.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
--------------------------------------------+------------------------
Hello,

I'd like to be able to add a `IF NOT EXISTS` clause when creating indexes
(both with AddIndex and AddIndexConcurrently).

I've read this ticket https://code.djangoproject.com/ticket/34298 where
Mariusz considers it's a bad idea (for constraints), and I get his point,
however I've a few counter arguments:
* I feel like the workflow "add an index in a deployed environment /
check it works as expected / add it to Django code" is quite common in
"real-life" applications, for now we have to write a custom
`SeparateDatabaseAndState` each time we do this
* The idea would be to enable this explicitly (either by adding a
`AddIndexIfNotExists` operation, or by adding a parameter to `AddIndex` /
`AddIndexConcurrently`), so people should know what they're doing when
using this.
* The `IF EXISTS` clause is already used when dropping the index, it
would be more consistent to be able to allow it when adding the index too
[https://github.com/django/django/blob/afc880571d5f5a16b977070b15014f9583524898/django/db/backends/postgresql/schema.py#L25]

--
Ticket URL: <https://code.djangoproject.com/ticket/34729>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#34729: Add explicit option to enable IF EXISTS / IF NOT EXISTS in PostgresQL index
operations

----------------------------------+--------------------------------------

Reporter: Laurent Tramoy | Owner: (none)

Type: New feature | Status: closed
Component: contrib.postgres | Version: 4.2
Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

----------------------------------+--------------------------------------
Changes (by Mariusz Felisiak):

* status: new => closed
* resolution: => wontfix

Comment:

I still think it is a bad idea for exactly the same reasons I already
mentioned in the #34298. Also, I don't think that separate operations or
extra arguments to control this behavior is a good idea, following this
path we could add the same to all migration operations. Why should index
creation be treated differently? Last but not least this syntax is not
supported by all database engines with built-in backends.

Please first start a discussion on the DevelopersMailingList, where you'll
reach a wider audience and see what other think, and
[https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
tickets/#closing-tickets follow the triaging guidelines with regards to
wontfix tickets.

--
Ticket URL: <https://code.djangoproject.com/ticket/34729#comment:1>