Re: Support json_errdetail in FRONTEND builds - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support json_errdetail in FRONTEND builds
Date
Msg-id ZfKwB_MygzQsQRji@paquier.xyz
Whole thread Raw
In response to Re: Support json_errdetail in FRONTEND builds  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: Support json_errdetail in FRONTEND builds
List pgsql-hackers
On Wed, Mar 13, 2024 at 11:20:16AM -0700, Jacob Champion wrote:
> Sounds good, split into v2-0002. (That gives me room to switch other
> call sites to the new API, too.) Thanks both!

That looks OK to me.  I can see 7~8 remaining sites where StringInfo
data is freed, like in the syslogger, but we should not touch the
StringInfo.

>>          case JSON_EXPECTED_STRING:
>> -            return psprintf(_("Expected string, but found \"%s\"."),
>> -                            extract_token(lex));
>> +            appendStringInfo(lex->errormsg,
>> +                             _("Expected string, but found \"%.*s\"."),
>> +                             toklen, lex->token_start);
>>
>> Maybe this could be wrapped in a macro to avoid copying around
>> token_start and toklen for all the error cases.
>
> I gave it a shot in 0001; see what you think.

That's cleaner, thanks.

Hmm, I think that it is cleaner to create the new API first, and then
rely on it, reversing the order of both patches (perhaps the extra
destroyStringInfo in freeJsonLexContext() should have been moved in
0001).  See the attached with few tweaks to 0001, previously 0002 @-@.
I'd still need to do a more serious lookup of 0002, previously 0001.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: type cache cleanup improvements
Next
From: Jeff Davis
Date:
Subject: Re: Built-in CTYPE provider