> On Jan 16, 2020, at 1:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> >>> Lastly, it strikes me that maybe pg_wchar.h, or parts of it, should >>> migrate over to src/include/common. But that'd be far more invasive >>> to other source files, so I've not touched the issue here. > >> I don't have a view on this. > > If anyone is hot to do this part, please have at it. I'm not.
I moved the file pg_wchar.h into src/include/common and split out most of the functions you marked as being suitable for the backend only into a new file src/include/utils/mbutils.h. That resulted in the need to include this new “utils/mbutils.h” from a number of .c files in the source tree. One issue that came up was libpq/pqformat.h uses a couple of those functions from within static inline functions, preventing me from moving those to a backend-only include file without making pqformat.h a backend-only include file. I think the right thing to do here is to move references to these functions into pqformat.c by un-inlining these functions. I have not done that yet. There are whitespace cleanup issues I’m not going to fix just yet, since I’ll be making more changes anyway. What do you think of the direction I’m taking in the attached? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pg_wchar.cleanup.patch.1
Description: Binary data
