Hi Adrian. Nothing has been done, no.
There seem to be a few competing options: 1. Allow max_length=None on Postgres (using a supports_unlimited_charfields, name!?, DB backend feature flag maybe 🤔) 2. Add an unlimited flag to CharField. 3. Have a subclass in contrib.postgres, similar to JKM's version Tom linked before <https://github.com/jacobian/django-postgres-unlimited-varchar/blob/master/django_postgres_unlimited_varchar.py> My guess would be 1 or 3. (I'd rather 3 than 2.) So proof-of-concepts implementing those would be the way forward I think. Kind Regards, Carlton On Wed, 5 Oct 2022 at 12:47, Adrian Torres <atorr...@redhat.com> wrote: > Sorry for reviving the thread but just ran into this issue again and > wanted to ask, has there anything been done to address this? > > For me having max_length=None mean "unlimited varchar" for Postgres and > being an error for any other database (or those that don't support > unlimited varchar) is the best solution, but I'm also ok with Carlton's > idea of having a subclass in contrib.postgres is an acceptable compromise. > > Cheers, > Adrian > > On Monday, August 17, 2020 at 11:26:39 AM UTC+2 t...@carrick.eu wrote: > >> It would work for my use-cases. It was mentioned that it's maybe not the >> best as a lot of fields subclass CharField, but I don't see a compelling >> argument for an unlimited email or slug field. The one problem I see is >> CICharField, you might want to make that unlimited - but the CI fields are >> more or less redundant on pg >= 12 once we have column collations in. So I >> think it's okay for now. Only problem I can see is if we add more CharField >> subclasses in the future... >> >> On Mon, 17 Aug 2020 at 11:02, Carlton Gibson <carlton...@gmail.com> >> wrote: >> >>> Would the subclass in contrib.postgres suggestion be acceptable? >>> >>> On Mon, 17 Aug 2020 at 10:31, Tom Carrick <t...@carrick.eu> wrote: >>> >>>> I'm not a fan of any solution either, really, even the one I suggested. >>>> >>>> I think adding a new kwarg, "unlimited" seems okay to me, though it >>>> feels a little redundant. >>>> >>>> I don't like the idea of using TextField, I find them semantically >>>> different. An unlimited varchar says to me "one possibly very long thing", >>>> whereas TextField feels more like it's free text, or a document, especially >>>> as the form fields are different. Subclassing CharField is an option, but >>>> the methods I've seen to do this makes it annoying. I need this so often >>>> that I do it all the time, but the code is so short that I don't want to >>>> bring in a new package to do it. Also, the popular ways to do this are not >>>> great. One way is to just set the max_length extremely high, which is not >>>> what I want ending up in the database, the other is something like this >>>> <https://github.com/jacobian/django-postgres-unlimited-varchar>, which >>>> works well, but will stop working well once column collations are in as >>>> that PR adds more stuff to CharField.__init__(). >>>> >>>> I think it's time we had something in Django, whatever that ends up >>>> being. >>>> >>>> On Sun, 16 Aug 2020 at 20:28, Carlton Gibson <carlton...@gmail.com> >>>> wrote: >>>> >>>>> Reading the history, I see an awful lot of -1s to the idea of a >>>>> default. >>>>> >>>>> I see “use a TextField” and “use a subclass” a few times, which were >>>>> my immediate thoughts just on the recent emails. >>>>> >>>>> On Sun, 16 Aug 2020 at 18:47, Tom Forbes <t...@tomforb.es> wrote: >>>>> >>>>>> I’m not a fan of implicit max_lengths. Is having to add a keyword >>>>>> argument to a model field really that much of a burden? And we also would >>>>>> likely never be able to change the default without headaches. >>>>>> >>>>>> On 12 Aug 2020, at 13:19, t...@carrick.eu <t...@carrick.eu> wrote: >>>>>> >>>>>> I'd like to revive this discussion and try to come to a consensus as >>>>>> it's something I find myself wishing for (for Postgres in particular). >>>>>> >>>>>> My suggestion, after reading through everything: >>>>>> >>>>>> Give CharField a default max_length that is consistent across all >>>>>> vendors. It doesn't really matter what the number is other than that it >>>>>> should be large enough to be useful but small enough to work everywhere. >>>>>> I >>>>>> think 100 or 255 are both fine options. >>>>>> >>>>>> If you set max_length=None explicitly, on Postgres this will use an >>>>>> unlimited varchar, on everything else will raise an exception on migrate. >>>>>> >>>>>> Any thoughts? >>>>>> >>>>>> Cheers, >>>>>> Tom >>>>>> >>>>>> On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote: >>>>>> >>>>>>> On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote: >>>>>>> >>>>>>> >>>>>>> > I’m not too keen on a contrib.pg field. CharField is the base >>>>>>> class of many >>>>>>> >>>>>>> >>>>>>> > fields, a __init__ kwarg approach such as max_length=None allows >>>>>>> us to >>>>>>> >>>>>>> >>>>>>> > reach those as well. >>>>>>> >>>>>>> >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> That's a good point; Can we enable max_length=None in a mixin? >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Django developers (Contributions to Django itself)" group. >>>>>> >>>>>> >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to django-develop...@googlegroups.com. >>>>>> >>>>>> >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/django-developers/dfaaa9d3-dff3-46a3-899f-dd7f4eddfe87n%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/django-developers/dfaaa9d3-dff3-46a3-899f-dd7f4eddfe87n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Django developers (Contributions to Django itself)" group. >>>>>> >>>>>> >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to django-develop...@googlegroups.com. >>>>>> >>>>>> >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/django-developers/468B12C0-2864-4221-9985-044F340E56E1%40tomforb.es >>>>>> <https://groups.google.com/d/msgid/django-developers/468B12C0-2864-4221-9985-044F340E56E1%40tomforb.es?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Django developers (Contributions to Django itself)" group. >>>>> >>>>> >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to django-develop...@googlegroups.com. >>>>> >>>> >>>>> >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/django-developers/CAJwKpyScwiRJWWebwjQZ4qoQz6_zuWZP9Q_RAs8bxzV0eRMoqQ%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/django-developers/CAJwKpyScwiRJWWebwjQZ4qoQz6_zuWZP9Q_RAs8bxzV0eRMoqQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers (Contributions to Django itself)" group. >>>> >>>> >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to django-develop...@googlegroups.com. >>>> >>>> >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZZN%3D%3D%3D77LQn%3DNAWz%3DazADCuG_bt4xVr5GuNbZW%2Bnu1rg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZZN%3D%3D%3D77LQn%3DNAWz%3DazADCuG_bt4xVr5GuNbZW%2Bnu1rg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/CAJwKpyR6FfkogPHup9gwqQUZ0n8QgQdZDDgCBRdh_m6%3DHui2iA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-developers/CAJwKpyR6FfkogPHup9gwqQUZ0n8QgQdZDDgCBRdh_m6%3DHui2iA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/f442ac46-e197-459f-8a04-18e0ad0c6058n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/f442ac46-e197-459f-8a04-18e0ad0c6058n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJwKpyS%2BjdnJVF5ksriaoYQLrvV-ZiDHpYfgB4sNObcsCQ%3DARQ%40mail.gmail.com.
