From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Gavan Schneider <list(dot)pg(dot)gavan(at)pendari(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martin Mueller <martinmueller(at)northwestern(dot)edu>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: A simple question about text fields |
Date: | 2021-06-18 06:49:01 |
Message-ID: | 2a26524e395daee321efe6ffc391fd2debec55dc.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2021-06-18 at 10:28 +1000, Gavan Schneider wrote:
> On 18 Jun 2021, at 9:34, David G. Johnston wrote:
> > On Thursday, June 17, 2021, Gavan Schneider <list(dot)pg(dot)gavan(at)pendari(dot)org> wrote:
> >
> > > My approach is to define such fields as ‘text’ and set a constraint using
> > > char_length(). This allows PG to do the business with the text in native
> > > form, and only imposes the cost of any length check when the field is
> > > updated… best of both worlds.
> > >
> >
> > Those are basically the same world…your alternative probably is strictly
> > worse than varchar(n) because of its novel way of implementing the same
> > functionality.
>
> Not sure if this is strictly true. Novelty per se is not always worse. :)
True in general, but not in this case.
There is no advantage in a "text" with a check constraint on the length,
that is, no added functionality.
And it is worse for these reasons:
- the performance will be worse (big reason)
- the length limit is less obvious if you look at the table definition
(small reason)
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | goldgraeber-werbetechnik | 2021-06-18 07:15:29 | short sql question |
Previous Message | David G. Johnston | 2021-06-18 06:10:05 | Re: Temporal tables as part of main release |