pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Chris Browne <cbbrowne@acm.org>
To: pgsql-performance@postgresql.org
Subject: Re: Optimization of this SQL sentence
Date: Tue, 17 Oct 2006 14:09:41 -0400
Message-ID: <60wt6y7r16.fsf@dba2.int.libertyrms.com> (raw)
References: <45349CDF.3090002@rentalia.com>
	<4534A35E.9030909@rentalia.com>
	<181E6D21-8326-4ED6-A9AE-6F9917C1C319@purefiction.net>
	<200610171729.19596.mweilguni@sime.com>
	<b42b73150610170951t33619da0u4851de1fbb1c0b0f@mail.gmail.com>

mmoncure@gmail.com ("Merlin Moncure") writes:
> 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?

Yeah, 255 seems silly to me.

If I'm going to be arbitrary, there are two better choices:

1.  80, because that's how many characters one can fit across a piece
    of paper whilst keeping things pretty readable;

2.  64, because that will fit on a screen, and leave some space for a
    field name/description.

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

No, I can't agree.  I'm pretty accustomed to languages that don't
pinch you the ways C does, and I still dislike having over-wide
columns because it makes it more difficult to generate readable
reports.
-- 
output = ("cbbrowne" "@" "linuxfinances.info")
http://linuxdatabases.info/info/unix.html
"Instant coffee is like pouring hot water over the cremated remains of
a good friend."



view thread (24+ messages)  latest in thread

Message-ID: <60wt6y7r16.fsf@dba2.int.libertyrms.com>
Permalink:  ../60wt6y7r16.fsf@dba2.int.libertyrms.com/
Also on:    postgresql.org/message-id/60wt6y7r16.fsf@dba2.int.libertyrms.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: cbbrowne@acm.org
  Subject: Re: Optimization of this SQL sentence
  In-Reply-To: <60wt6y7r16.fsf@dba2.int.libertyrms.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox