Multibyte in autoconf - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Multibyte in autoconf
Date
Msg-id Pine.LNX.4.20.9912061730530.8886-100000@localhost.localdomain
Whole thread Raw
Responses Re: [HACKERS] Multibyte in autoconf
List pgsql-hackers
This belongs to the chapter "initdb weirdnesses", if you will. I have long
been confused about this, but now I think I have the answer. Could someone
from the multibyte camp please confirm this.

When I configure --with-mb=FOO, the only place FOO is actually used is in
initdb as the default encoding of the database system you are creating
(can be overriden with --pgencoding). The rest of the source code only
does occasional #ifdef MULTIBYTE checks. This sort of arrangement is
questionable for a number of reasons:

1) It's not very clear to the casual observer (=end user). I was lead to
believe that the database system you are compiling will only support the
FOO encoding and I used several --with-mb's if I wanted more.

2) It is very well possible that one initdb instance can be used to
install databases in several locations with varying encodings.

3) I might sound like a broken record, but autoconf is not for controlling
runtime behavior.

While the notion of having a default encoding is perhaps not so bad (but
how often do you do initdb?) it could be introduced via other mechanisms,
such as environment variables. (I am contradicting earlier emails now, but
I'm not sure of a good way myself, yet.) The current approach causes all
kinds of structural hazards in the overall view of things. I propose that
--with-mb be replaced by --enable-mb (how about --enable-multibyte?). This
is nothing urgent, but I would like to know what you think.
-Peter


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden




pgsql-hackers by date:

Previous
From: Karel Zak - Zakkr
Date:
Subject: Re: [HACKERS] FOREIGN KEY and shift/reduce
Next
From: Kyle Bateman
Date:
Subject: Re: [HACKERS] Raising funds for PostgreSQL