Gregory Stark <gsstark@MIT.EDU> writes:
> Peter Eisentraut <peter_e@gmx.net> writes:
>
> > Gregory Stark wrote:
> > > > But that won't help in the example you posted upthread, because
> > > > char(N) is not fixed-length.
> > >
> > > Sure it is because any sane database--certainly any sane database
> > > using char(N)--is in C locale anyways.
> >
> > This matter is completely independent of the choice of locale and
> > therefore any unilateral redefinition of sanity that you might come up
> > with.
>
> Except it isn't. If you're dealing with fixed length ascii codes from existing
> databases you interoperate with then you will have problems if you initialize
> your database in a non-C locale. Interpreting those codes in your locale will
> be do incorrect things like treat them as case insensitive or ignore spaces in
> collation, etc.
Oh, I think I misread your comment. You're saying the choice of encoding is
independent of the choice of locale.
Sure, if you're using UTF8 then how efficiently Postgres stores fixed length
data types isn't terribly relevant to you. Just as it isn't relevant if you're
storing other variable length data types.
But why would you use UTF8 to encode fixed length ascii strings?
--
greg