On Wed, 8 Dec 1999, Tatsuo Ishii wrote:
> > If no --pgencoding, you get default (non-multibyte) coding even
> > if you compiled with --enable-mb.
>
> Not agreed. I think it would be better to give an error if no default
> encoding is not sepecified if configured with --enable-mb. Reasons:
>
> 1) Users tend to use only one encoding rather than switching multiple
> encoding database. Thus major encoding for the user should be properly
> set as the default.
Users also initdb only once, and that is the time to *choose* what they
want. Then and only then. Once they're done with that they'll never have
to worry about it again.
> 2) if non-multibyte coding such as SQL_ASCII is accidently set as the
> default, and if a multi-byte user create a database with no encoding
> arugument, the result would be a disaster.
Huh, so if I compile my database with multibyte and then I then I choose
to not have a default encoding in template1 but maybe I want to have the
multibyte option available for some other database later on, that will be
a disaster? Not so good.
What I'm also thinking of is the the package maintainer. They should be
able to provide a "neutral" yet multibyte (and locale, and cyrillic)
enabled package, and one should be able to use that even if one doesn't
want to use the multibyte features right now or at all.
Also, it should not be initdb's job to verify that the encodings are
correct, supported, etc. The backend should find that out itself. That
eliminates duplication of the same logic, which the backend can do better
anyway.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
