Re: making the backend's json parser work in frontend code

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: making the backend's json parser work in frontend code
Date: 2020-01-20 07:02:37
Message-ID: 0B442DD9-0C4D-4BC3-9753-3EC23563415A@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Jan 16, 2020, at 1:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 Content-Type Size
pg_wchar.cleanup.patch.1 application/octet-stream 74.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message david.turon 2020-01-20 07:39:35 Re: empty range
Previous Message Michael Paquier 2020-01-20 06:45:40 Re: Physical replication slot advance is not persistent