I wrote:
> Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
>> 1. change enough of the build system so that pg_encoding_mbcliplen is
>> available. (Offhand I see no reason why we couldn't move the
>> function from mbutils.c to wchar.c, but I haven't tried.)
> I'd be in favor of this if it doesn't turn out to require nasty
> contortions. My gut feeling (like yours, without having looked) is that
> the incremental amount of code to be moved into wchar.c wouldn't be much.
Actually, on second thought --- the issue here is not so much how much new
code shows up in libpgcommon, and more that executables using stringinfo.o
will now find themselves pulling in all of wchar.o, where before they
might've pulled in none of it. We need to look at how much code bloat
ensues. In the end it might be smart to put this new functionality in
some separate source file instead of dropping it into stringinfo.c.
(It could also be that all the executables that need stringinfo.o are
already pulling in wchar functionality for other reasons, but we should
check the code-size implications before assuming this is fine.)
regards, tom lane
