Re: Optimization of this SQL sentence

From: Ruben Rubio <ruben(at)rentalia(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Optimization of this SQL sentence
Date: 2006-10-18 07:06:20
Message-ID: 4535D26C.1010404@rentalia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Why do we have limits on this, for example?
contacto varchar(255)

1) First of all, this is a web application. People use to enter really
strange thinks there, and a lot of rubbish. So, as someone commented
before, I am ok with the idea of limit the field.

2) Again, this is a web application. We could just limit the "field
front end length" but this will be not secure. We could limit the field
front end, and limit it with the code that process the data, but is much
secure if we just limit field in database.

Why 255?
This is free field. We are interested in users enter as much data as
needed (with a limit, we no not want "The Quijote" in that field)

People use to imput as spected:
"Contact: Baltolomé Peralez."
But people also inserts thinks as:
"Contact: In the mornings, Bartolomé Perales, in the afternoons Juan
Perales in the same telephone number"

In the context of the application, we are not interested in stopping the
user with a message "Hey, Your contact is too long". We want the user to
go on. That's why 255. We could insert 260. Or maybe 250. But someone
decided 255 and for me its OK.

Please remember that I just put some data of a large applications, and
there is thinks there that has sense in context.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNdJsIo1XmbAXRboRAuGVAKCupfXOHwxXOPHFdq+K6S0lXWNZUwCgml1i
CS0eEJcQndEJb7h7Nsfh1CM=
=0gpW
-----END PGP SIGNATURE-----

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Mario Weilguni 2006-10-18 09:31:44 Re: Optimization of this SQL sentence
Previous Message Tom Lane 2006-10-18 05:19:39 Re: Jdbc/postgres performance