Robert Treat <xzilla@users.sourceforge.net> writes:
> Unless your application requires a 30 character limit at the logical
> level, use text.
And if it does, use varchar(30). I will bet a very good lunch that
char(30) will be a complete dead loss on *every* measure: speed, disk
space, and convenience.
char(N) is not really fixed-width in Postgres, because N is measured
in characters not bytes (which are not the same thing if you use a
multibyte character encoding). Therefore, there are no optimizations
that could allow it to outperform varchar(N). When you consider the
extra cost of performing the padding step, the extra storage and I/O
incurred for all those pad blanks, and the client-side headaches of
having to trim the unwanted blanks again, it's just guaranteed to be
a loser.
The only case in which I could recommend char(N) is where you have
application semantics that constrain a field to exactly N characters
(postal codes are one common example). If the semantics are "at
most N characters", use varchar(N). If you are picking N out of the
air, don't bother: use text.
regards, tom lane
