Re: [PATCH] json_lex_string: don't overread on bad UTF8

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: [PATCH] json_lex_string: don't overread on bad UTF8
Date: 2024-05-08 14:01:08
Message-ID: CAOYmi+kSYoLZm9OTa022VKOrXOmbKuGvanNus59gDHg0kAhzMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 7, 2024 at 10:31 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> But looking closer, I can see that in the JSON_INVALID_TOKEN case,
> when !tok_done, we set token_terminator to point to the end of the
> token, and that would include an incomplete byte sequence like in your
> case. :/

Ah, I see what you're saying. Yeah, that approach would need some more
invasive changes.

> This situation makes me
> uncomfortable and we should put more effort in printing error messages
> in a readable format, but that could always be tackled later as a
> separate problem.. And I don't see something backpatchable at short
> sight for v16.

Agreed. Fortunately (or unfortunately?) I think the JSON
client-encoding work is now a prerequisite for OAuth in libpq, so
hopefully some improvements can fall out of that work too.

> Thoughts and/or objections?

None here.

Thanks!
--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2024-05-08 14:06:53 Re: AIX support
Previous Message Robert Haas 2024-05-08 13:57:50 Re: CREATE DATABASE with filesystem cloning