Re: Optimization of this SQL sentence - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Optimization of this SQL sentence
Date
Msg-id b42b73150610170951t33619da0u4851de1fbb1c0b0f@mail.gmail.com
Whole thread Raw
In response to Re: Optimization of this SQL sentence  (Mario Weilguni <mweilguni@sime.com>)
Responses Re: Optimization of this SQL sentence  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-performance
On 10/17/06, Mario Weilguni <mweilguni@sime.com> wrote:
> Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo:
> > Lastly, note that in PostgreSQL these length declarations are not
> > necessary:
> >
> > contacto varchar(255),
> > fuente varchar(512),
> > prefijopais varchar(10)
> >
> > Instead, use:
> >
> > contacto text,
> > fuente text,
> > prefijopais text
> >
> > See the PostgreSQL manual for an explanation of varchar vs. text.
>
> Enforcing length constraints with varchar(xyz) is good database design, not a
> bad one. Using text everywhere might be tempting because it works, but it's
> not a good idea.

while you are correct, i think the spirit of the argument is wrong
becuase there is no constraint to be enforced in those fields.  a
length constraint of n is only valid is n + 1 characters are an error
and should be rejected by the database.  anything else is IMO bad
form.  There are practial exceptions to this rule though, for example
client technology that might require a length.

so, imo alexander is correct:
contacto varchar(255)

...is a false constraint, why exactly 255? is that were the dart landed?

specifically limiting text fields so users 'don't enter too much data'
is a manifestation c programmer's disease :)

note I am not picking on the OP here, just weighing in on the
constraint argument.

merlin

pgsql-performance by date:

Previous
From: Mario Weilguni
Date:
Subject: Re: Optimization of this SQL sentence
Next
From: Chris Browne
Date:
Subject: Re: Optimization of this SQL sentence