Re: Newbee question "Types"

On Thu, Dec 05, 2002 at 06:07:44PM -0800, Josh Berkus wrote:
> Bruce gives the example of State Codes, which is a classic example, and
> something I did myself in the past.   However, I generally found myself
> forced to expand the state code field; the abbreviation for some US
> Territories is 4 characters, and some countries use 3 for provinces.   At
> that point, I very much needed to use VARCHAR, since I don't want 'CA__' as
> my state.
>
> CHAR can be a reminder to you, the developer, in reading the schema, that you
> are expecting a string of a precise length.     But I do not see it as an
> effective or useful constraint on input in real applications.  A constraint
> statement, like the above, is far more effective.

With some ODBC apps, CHAR can behave in less-than-expected ways.

CREATE TABLE c (c CHAR(5));
INSERT INTO c VALUES ('a');

will put a 'a____' into the field. PG will let you find this with

SELECT * FROM c WHERE c='a';

because it handles the padding v. non-padding fine.

However, an ODBC app like Access won't find it w/a normal,
Access-mediated query. You have to specify WHERE c='a____' to find it.
*Unless* you're writing a pass-through query (which Access doesn't
touch, but hands directly to PostgreSQL). So you can get different
behavior w/o expecting it.

If your app might be used in different environments, I'd think before
using CHAR, even in places that might seem 'safe' or 'obvious'.

- J.
--

Joel BURTON  |  joel@joelburton.com  |  joelburton.com  |  aim: wjoelburton
Independent Knowledge Management Consultant