Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> The API is different in each case: if we want it available in frontend,
> we need to pass the encoding as a parameter rather than use
> GetDatabaseEncoding().
Hm, yeah, so that's another reason we aren't going to be sharing this
code exactly with frontend. Given that, dropping it under utils/mb
seems fine for now. (I'm still wondering how much of utils/mb could
be pushed over to src/common, but that seems like an independent
project.)
Some quick review of v19:
* If it's going into utils/mb, then you should update utils/mb/README.
(Or else we should get rid of that file's explanation of all the .c
files in its directory.)
* The file header comment for stringinfo_mb.c should perhaps explain
why we didn't just drop this into stringinfo.c, along the lines
of "This is separate from stringinfo.c so that frontend users of that
file need not pull in a bunch of multibyte encoding support."
* The file header comment for stringinfo_mb.c gives its path incorrectly.
* What's the need for including utils/memutils.h here?
* Still no documentation of maxlen in the .c file, and the docs added
to the .h file are confused (what "given encoding"? also it should say
"bytes" not "characters").
* This patch shouldn't be touching stringinfo.c at all anymore.
* I'm kind of dubious that stringinfo.h is where to put the extern
either; with where we're at now, perhaps pg_wchar.h is better.
regards, tom lane
