| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Mike Nolan <nolan(at)gw(dot)tssi(dot)com>, josh(at)agliodbs(dot)com, Bill Moran <wmoran(at)potentialtech(dot)com>, Jeff <threshar(at)torgo(dot)978(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Fixed width rows faster? |
| Date: | 2004-03-06 10:01:18 |
| Message-ID: | 4049A16E.1040606@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> If you have an actual business-logic requirement to restrict a field to
> no more than N characters, then by all means use varchar(N); that's
> what it's for. But I agree with what I think Josh meant: there is very
> seldom any non-broken reason to have a hard upper limit on string
> lengths. If you think you need varchar(N) you should stop and ask
> why exactly. If you cannot give a specific, coherent reason why the
> particular value of N that you're using is the One True Length for the
> field, then you really need to think twice.
One nice reason to have like VARCHAR(4096) or whatever is that if there
is a bug in your website and you forget to length check some user input,
it stops them from screwing you by uploading megs and megs of data into
a 'firstname' field, say.
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Eric Jain | 2004-03-06 13:17:35 | Re: Fixed width rows faster? |
| Previous Message | Tom Lane | 2004-03-06 05:53:49 | Re: Fixed width rows faster? |