From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Multibyte in autoconf |
Date: | 1999-12-09 01:31:20 |
Message-ID: | 29133.944703080@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-12-09 01:38:30 | Re: [HACKERS] More initdb follies |
Previous Message | Hiroshi Inoue | 1999-12-09 01:04:01 | Re: [HACKERS] Multibyte in autoconf |