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

From Robert Haas
Subject Re: making the backend's json parser work in frontend code
Date
Msg-id CA+TgmoaoO-pFD29xm0izRBYpBEqKA23ZhQ6Wdjy=tfeNtL_Pfw@mail.gmail.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>)
Responses Re: making the backend's json parser work in frontend code  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jan 16, 2020 at 3:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > 0001 moves wchar.c from src/backend/utils/mb to src/common. Unless I'm
> > missing something, this seems like an overdue cleanup.
>
> Here's a reviewed version of 0001.  You missed fixing the MSVC build,
> and there were assorted comments and other things referencing wchar.c
> that needed to be cleaned up.

Wow, thanks.

> Also, it seemed to me that if we are going to move wchar.c, we should
> also move encnames.c, so that libpq can get fully out of the
> symlinking-source-files business.  It makes initdb less weird too.

OK.

> I took the liberty of sticking proper copyright headers onto these
> two files, too.  (This makes the diff a lot more bulky :-(.  Would
> it help to add the headers in a separate commit?)

I wouldn't bother making it a separate commit, but please do whatever you like.

> Another thing I'm wondering about is if any of the #ifndef FRONTEND
> code should get moved *back* to src/backend/utils/mb.  But that
> could be a separate commit, too.

+1 for moving that stuff to a separate backend-only file.

> 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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: SlabCheck leaks memory into TopMemoryContext
Next
From: Robert Haas
Date:
Subject: Re: our checks for read-only queries are not great