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+TgmoZffsCGkOQkopwQhnrz5p8vVLTL+SKh+=4nN4jQCSVJOw@mail.gmail.com
Whole thread Raw
In response to Re: making the backend's json parser work in frontend code  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: making the backend's json parser work in frontend code
Re: making the backend's json parser work in frontend code
List pgsql-hackers
On Sun, Jan 26, 2020 at 9:05 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> Ok, the tests pass.  Here are those two patches again, both regenerated with a fresh invocation of ‘git
format-patch’.

Regarding 0006:

+#ifndef FRONTEND
 #include "miscadmin.h"
-#include "utils/jsonapi.h"
+#endif

I suggest

#ifdef FRONTEND
#define check_stack_depth()
#else
#include "miscadmin.h"
#endif

- lex->token_terminator = s + pg_mblen(s);
+ lex->token_terminator = s +
pg_wchar_table[lex->input_encoding].mblen((const unsigned char *) s);

Can we use pq_encoding_mblen() here? Regardless, it doesn't seem great
to add more direct references to pg_wchar_table. I think we should
avoid that.

+ return JSON_BAD_PARSER_STATE;

I don't like this, either. I'm thinking about adding some
variable-argument macros that either elog() in backend code or else
pg_log_fatal() and exit(1) in frontend code. There are some existing
precedents already (e.g. rmtree.c, pgfnames.c) which could perhaps be
generalized. I think I'll start a new thread about that.

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



pgsql-hackers by date:

Previous
From: Asim R P
Date:
Subject: Re: Replication & recovery_min_apply_delay
Next
From: Ranier Vilela
Date:
Subject: Re: [PATCH] Windows port, fix some resources leaks