From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Mario Weilguni" <mweilguni(at)sime(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org, "Alexander Staubo" <alex(at)purefiction(dot)net>, "Ruben Rubio" <ruben(at)rentalia(dot)com> |
Subject: | Re: Optimization of this SQL sentence |
Date: | 2006-10-17 16:51:19 |
Message-ID: | b42b73150610170951t33619da0u4851de1fbb1c0b0f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 10/17/06, Mario Weilguni <mweilguni(at)sime(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Browne | 2006-10-17 18:04:47 | Re: Optimization of this SQL sentence |
Previous Message | Alexander Staubo | 2006-10-17 15:50:41 | Re: Optimization of this SQL sentence |