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

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: making the backend's json parser work in frontend code
Дата
Msg-id 0B442DD9-0C4D-4BC3-9753-3EC23563415A@enterprisedb.com
обсуждение исходный текст
Ответ на Re: making the backend's json parser work in frontend code  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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



Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Physical replication slot advance is not persistent
Следующее
От: david.turon@linuxbox.cz
Дата:
Сообщение: Re: empty range