I wrote:
> Having said that, I also notice these dependencies:
> ...
> src/bin/initdb/encnames.c -> ../../../src/backend/utils/mb/encnames.c
> src/interfaces/libpq/encnames.c -> ../../../src/backend/utils/mb/encnames.c
> ...
> which seem like they'd be better handled by moving those files into
> src/common/.
After poking around a bit, it seems like it ought to be a win to move
both encnames.c and wchar.c into src/common/, as both of those modules
are meant to be built for both backend and frontend environments. The
stumbling block is pg_wchar.h, which is a total fail modularity-wise,
as it does not bother to distinguish stuff which should be visible to the
general backend from stuff which should be visible to frontend programs
from stuff which is solely of interest to encoding conversion logic (and
in many cases only to *particular* conversions). I think we should not do
this move without figuring out which parts of that file sanely belong in a
src/include/common/ header file and which don't. That's not something
that I feel like tackling right now, as it's been in that same messy state
for awhile and recent changes haven't made it worse. But it ought to be
revisited at some point.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
