Alvaro Herrera <alvhe...@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