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