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

From Jacob Champion
Subject Re: Support json_errdetail in FRONTEND builds
Date
Msg-id CAOYmi+mspeQ0GYFutTYiswZkMGgnLmB5ZvJEsj_ciamFHcrBNw@mail.gmail.com
Whole thread Raw
In response to Re: Support json_errdetail in FRONTEND builds  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Support json_errdetail in FRONTEND builds
List pgsql-hackers
On Tue, Mar 12, 2024 at 11:38 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Tue, Mar 12, 2024 at 08:38:43PM -0400, Andrew Dunstan wrote:
> > yeah, although maybe worth a different patch.
>
> I've wanted that a few times, FWIW.  I would do a split, mainly for
> clarity.

Sounds good, split into v2-0002. (That gives me room to switch other
call sites to the new API, too.) Thanks both!

> This does not stress me much, either.  I can see that OAuth introduces
> at least two calls of json_errdetail() in libpq, and that would matter
> there.

Yep.

>          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.

Thanks,
--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Jelte Fennema-Nio
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Next
From: Tom Lane
Date:
Subject: Re: Reports on obsolete Postgres versions