Re: [HACKERS] Multibyte in autoconf - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Multibyte in autoconf
Date
Msg-id 29133.944703080@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Multibyte in autoconf  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> The fact that you have configured with --enable-multibyte doesn't mean you
> have to use it. Just because a program is locale capable, doesn't mean you
> have to decide on the default locale at compile time.

Well, if you don't determine a default locale at configure/compile time,
what that *really* means is that the default was hardwired in even
earlier, ie, when the program was written.  (Or else it means that there
is no default: if we did that, users would be required to explicitly
give an encoding choice whenever they run initdb.)

Seems to me that Tatsuo is right that setting a site-specific default
encoding at configure time is handy, and *also* that Peter is right that
the encoding should be selectable at initdb time.  But where's the
conflict?  We can accept "--with-mb=FOO" at configure time, with the
understanding that the *only* thing FOO is used for is to set the
default value of initdb's --pgencoding switch.  You override FOO by
giving an explicit --pgencoding switch when you do initdb.  People
building generic multibyte-capable RPMs would probably configure with
FOO=ASCII (or whatever the non-multibyte encoding is called).  Seems
like that should satisfy everyone.  Have I missed something?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: [HACKERS] Multibyte in autoconf
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] More initdb follies