From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "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-16 20:21:38 |
Message-ID: | CA+TgmoaoO-pFD29xm0izRBYpBEqKA23ZhQ6Wdjy=tfeNtL_Pfw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 16, 2020 at 3:11 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-01-16 20:22:28 | Re: our checks for read-only queries are not great |
Previous Message | Tomas Vondra | 2020-01-16 20:21:28 | Re: SlabCheck leaks memory into TopMemoryContext |