#34955: Make available the string concatenation operator `||`  for PostgreSQL
-------------------------------------+-------------------------------------
     Reporter:  Paolo Melchiorre     |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  dev
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:  field, database,     |             Triage Stage:
  generated, output_field            |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Paolo Melchiorre):

 * type:  New feature => Bug


Comment:

 Replying to [comment:1 Mariusz Felisiak]:
 > I'm not convinced, there are other built-in functions that could be
 implemented differently and currently cannot be used in `GeneratedField`s

 The string concatenation operator `||` is not an exotic function specific
 to PostgreSQL, but an operator already used in other database backends, so
 your concern about the possible increase in requests to add new database
 functions to databases does not apply.

 I would add that I would have liked to open this issue since the
 introduction of functional indexes in Django 3.2, but I never did so due
 to lack of time.

 I decided to open this issue now after seeing that the choice to use the
 non-immutable concatenation function `CONCAT` instead of the immutable
 concatenation operator `||` in the PostgreSQL backend also affects the
 case of `GeneratedFields`.

 > I'm pessimistic about adding multiple new functions for such cases. This
 may open a can of worms. The current thread is to keep Django a core
 framework, not providing every utility which might be useful.

 Among other things, the string concatenation example is the most used to
 explain Generated Fields (e.g [https://fly.io/django-beats/new-goodies-in-
 django-50/#generated-fields fly.io], [https://djangochat.com/episodes/git-
 and-django-50-adam-johnson djangochat.com],
 [https://www.paulox.net/2023/11/07/database-generated-columns-part-1
 -django-and-sqlite/#the-user-model paulox.net], ...), but, due to this bug
 in the PostgreSQL backend database, it only works on a subset of Django
 backend databases, unlike the current thread of keeping Django a core
 framework, as you reiterated.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018baeb0a881-adc080b3-f94e-4e35-bbb2-7ca64fb84d6e-000000%40eu-central-1.amazonses.com.

Reply via email to