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.
> On Mar 5, 2016, at 3:05 AM, Marc Tamlyn <marc.tam...@gmail.com> wrote: > > Voting: > > 1) should there be a default? > > I'm lazy, so I would be happy to have one. Where validation matters you can > change it, where it doesn't you don't have to. I'd draw an analogy to > (Positive)(Small)IntegerField - I often use the normal one when I mean some > variant of validation, or some other max/min value. > > 2) how to make it easy to have no limit on PG? > > If it's truly pg specific, then a contrib.pg field seems fine, though > probably call it UnlimitedCharField for lack of ambiguity. > > M > > On 1 Mar 2016 1:11 a.m., "Markus Holtermann" <i...@markusholtermann.eu> wrote: > From what I understand you will have a hard time doing that at all: > > On PG could go with a 'max_length=None' in a 3rd party app. But that wouldn't > be supported on any other database backend. Which means you're limiting your > app to PG. On the other hand you could make your app database independent by > using a TextField which has pretty much the same performance on PG as a > VARCHAR() and is available on other backends. But may perform bad on other > backends. But there's no way to have a text of unlimited length on MySQL > other than a TEXT column. > > TL;DR: you can't achieve both ways anyway. Neither now nor if we change the > behavior of Django's max_length attribute on CharFields. > > /Markus > > On Tuesday, March 1, 2016 at 11:00:29 AM UTC+11, Cristiano Coelho wrote: > I find that using TextField rather than CharField just to make postgres use > varchar() is a terrible idea, if you are implementing an reusable app and it > is used on a backend like MySQL where TextFields are created as text columns > which are horribly inneficient and should be avoided at any cost you will > have a really bad time. > I'm not sure about postgres but I want to believe that using varchar without > limits has also some performance considerations that should be taken care of. > > El lunes, 29 de febrero de 2016, 17:58:33 (UTC-3), Shai Berger escribió: > Hi, > > Thank you, Aymeric, for summing up the discussion this way. The division into > two separate problems is indeed required, and I fully support the idea of > setting max_length's default to 100 or 120. > > There seem to be just two points worth adding to your summary: > > On Monday 29 February 2016 11:19:02 Aymeric Augustin wrote: > > > > 2) How can we make it easy for PostgreSQL users to just use VARCHAR()? > > > > Since this is a PostgreSQL-specific feature, having a variant of CharField > > in django.contrib.postgres that supports and perhaps even defaults to > > unlimited length shouldn’t be controversial. > > > > The first -- I believe it was raised very early on by Christophe Pettus -- is > that Django already has a field that manifests on PG as VARCHAR(), and that > is > TextField. However, I don't like the idea that PG users should be using > TextField(widget=TextInput) as a replacement for CharField; I find that > counter-intuitive -- even if just because it is a "bad name". Names are > important. > > The second -- in response to a comment made by Josh Smeaton -- is that having > django.db.models.CharField with default max_lenth=N (for some finite N) and > django.contrib.postgres.CharField with default max_length=None (meaning > infinity) sounds like a bad idea. > > > > > I hope this helps! > > I'm certain it did! > > Shai. > > -- > 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 post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/71e5e743-29bb-4dba-9bf4-6948ab2d1fa9%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > 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 post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMwjO1Gj3E4_83qdbQmQwXe_WdTXUf7yuZ44-aQ9jgvJN9-5sg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/95635BD4-26EE-4948-A45A-CECFE83A501C%40gmail.com. For more options, visit https://groups.google.com/d/optout.
