From: | Ian Barwick <barwick(at)gmx(dot)net> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: A modest proposal for a FAQ addition |
Date: | 2003-01-12 18:02:30 |
Message-ID: | 200301121902.30863.barwick@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sunday 12 January 2003 17:55, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> > > OK, new text is:
> >
> > I think Tom specifically wanted the notion "don't use CHAR(n), it has
> > unusual behavior" to appear prominently in the FAQ. The current text
> > simply rehashes the documentation.
>
> I can't say "don't use CHAR(n)" because there are valid reasons to use
> it.
I think what Tom is saying is "always use VARCHAR(n) unless you know
for sure CHAR(n) is what you want, because if you slept through that part of
the SQL course CHAR(n) is not what you might think."
How about something like:
"4.14.1 Why do operations on CHAR(n) columns produce strange results?
Data inserted into a CHAR(n) column will be automatically padded with blanks
to the specified column length. This makes some operations, particularly
comparisions, appear to return unexpected results. For example, if you
insert the string 'hello' (5 characters) into a column defined as CHAR(8) it
will become 'hello ' (8 characters) and simple comparisions with the
original 'hello' will fail.
Always define columns with VARCHAR(n) unless you have specific reasons for
using CHAR(n)."
Ian Barwick
barwick(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-12 18:15:08 | Re: A modest proposal for a FAQ addition |
Previous Message | Bruce Momjian | 2003-01-12 16:55:23 | Re: A modest proposal for a FAQ addition |