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.pg.gavan@xxxxxxxxxxx> 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
