From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Grega Jesih <Grega(dot)Jesih(at)actual-it(dot)si>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: text fields and performance for ETL |
Date: | 2021-11-05 14:32:12 |
Message-ID: | CAKFQuwbVkQAySX+KPiQT8miAP4D0mgG-xzZDCCxtb8DFB0NTog@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Friday, November 5, 2021, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> >
> > Perhaps, right before the tip you quoted, something like that:
> >
> > If your use case requires a length limit on character data, or
> compliance
> > with the SQL standard is important, use "character varying".
> > Otherwise, you are usually better off with "text".
>
> I can support that if others think it is valuable.
>
>
The motivating complaint is that we should be encouraging people to use
varchar(4000) instead of text so external tools can optimize. If we are
not going to do that I really don’t see the pointing in changing away from
out current position of “only use text”. True length limit requirements
for data are rare, and better done in constraints along with all other the
other constraint that may exist for the data. I believe comments with
respect to the SQL standard are already present and adequate.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2021-11-05 15:27:33 | Re: text fields and performance for ETL |
Previous Message | Alvaro Herrera | 2021-11-05 14:25:25 | Re: vacuumdb --analyze-in-stages |