Robert Haas <robertmh...@gmail.com> writes: > ... However, I decided to spend today doing some further > investigation of an alternative approach, namely making the backend's > existing JSON parser work in frontend code as well. I did not solve > all the problems there, but I did come up with some patches which I > think would be worth committing on independent grounds, and I think > the whole series is worth posting. So here goes.
In general, if we can possibly get to having one JSON parser in src/common, that seems like an obviously better place to be than having two JSON parsers. So I'm encouraged that it might be feasible after all. > 0001 moves wchar.c from src/backend/utils/mb to src/common. Unless I'm > missing something, this seems like an overdue cleanup. FWIW, I've been wanting to do that for awhile. I've not studied your patch, but +1 for the idea. We might also need to take a hard look at mbutils.c to see if any of that code can/should move. > Since I wrote my very first email complaining about the difficulty of > making the backend's JSON parser work in a frontend environment, one > obstacle has been knocked down: StringInfo is now available in > front-end code (commit 26aaf97b683d6258c098859e6b1268e1f5da242f). The > remaining problems (that I know about) have to do with error reporting > and multibyte character support; a read of the patches is suggested > for those wanting further details. The patch I just posted at <2863.1579127...@sss.pgh.pa.us> probably affects this in small ways, but not anything major. regards, tom lane