Re: making the backend's json parser work in frontend code - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: making the backend's json parser work in frontend code
Date
Msg-id 0B442DD9-0C4D-4BC3-9753-3EC23563415A@enterprisedb.com
Whole thread Raw
In response to Re: making the backend's json parser work in frontend code  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> On Jan 16, 2020, at 1:24 PM, Tom Lane <tgl@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



Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Physical replication slot advance is not persistent
Next
From: david.turon@linuxbox.cz
Date:
Subject: Re: empty range