Re: Support json_errdetail in FRONTEND builds

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, alvherre(at)alvh(dot)no-ip(dot)org
Subject: Re: Support json_errdetail in FRONTEND builds
Date: 2024-03-13 18:20:16
Message-ID: CAOYmi+mspeQ0GYFutTYiswZkMGgnLmB5ZvJEsj_ciamFHcrBNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 12, 2024 at 11:38 PM Michael Paquier <michael(at)paquier(dot)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 Content-Type Size
v2-0002-Add-a-helper-function-for-cleaning-up-StringInfos.patch application/octet-stream 6.2 KB
v2-0001-common-jsonapi-support-json_errdetail-in-FRONTEND.patch application/octet-stream 8.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-03-13 18:21:20 Re: Reports on obsolete Postgres versions
Previous Message Jelte Fennema-Nio 2024-03-13 18:18:07 Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs