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

From Mahendra Singh Thalor
Subject Re: making the backend's json parser work in frontend code
Date
Msg-id CAKYtNAr_PzXtcx8DNQg_KERiqv25O-mx2bOb_dptBbLOSVwbug@mail.gmail.com
Whole thread Raw
In response to Re: making the backend's json parser work in frontend code  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: making the backend's json parser work in frontend code  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, 27 Jan 2020 at 19:00, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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.
>

Hi,
I can see one warning on HEAD.

jsonapi.c: In function ‘json_errdetail’:
jsonapi.c:1068:1: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^

Attaching a patch to fix warning.

Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: JIT performance bug/regression & JIT EXPLAIN
Next
From: Robert Haas
Date:
Subject: Re: JIT performance bug/regression & JIT EXPLAIN