I attached v2, which contains the following notable changes since v1:
* I removed the incremental parser support, based on Andrew's comment
in another thread[1].
* I corrected many corner-case issues compared to v1, mainly based on
more fuzz testing against the json5 reference implementation[2]. v2
also passes the official json5-tests[3] suite completely, the
patchset's own regression suite now includes everything from
json5-tests, and more.
* I did extensive performance testing for the standard json path, and
made several modifications based on this. v2 only shows +-1% noise
compared to it in release builds
* v2 includes unicode_category in lipq, resulting in a ~70kb size
increase there. This is required for proper json5 compliance
(whitespace and identifier character classification), but if it is too
significant, we can decide to skip this part
[1]: https://postgr.es/m/CAD5tBcJeywJ%2B-UcedzJfG%2BfX2EWC_vQXTFVN6_MUFXY9Mebjhw%40mail.gmail.com
[2]: https://github.com/json5/json5
[3]: https://github.com/json5/json5-tests
On Wed, Jul 15, 2026 at 12:10 AM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
>
> Hello,
>
> During the prototyping of configuration format proposal[1] I started
> with a JSON based approach. As JSON isn't that human-friendly to
> write, that prototype also needed a JSON5 compatible parser to improve
> usability. I think this would be a useful improvement on its own: it
> could serve as functionality available to end users in the SQL
> interface and as an improved internal parser for extension authors.
>
> JSON5 is a relaxed version of the JSON standard, a superset of the
> original specification, which allows several additional syntax
> features:
>
> * Single line // and block /* comments */
> * trailing commas
> * unquoted object keys
> * single quoted strings
> * multi-line strings
> * extended number formats: hexadecimal, leading/trailing decimal
> point, plus sign, infinity and NaN
>
> To make the proposal easier to review and read, I cleaned it up, added
> a nicely structured test suite, and separated it into feature commits.
> The first patch can be interesting by itself, as JSON with Comments
> (JSONC) is a separate variant that would be a valid improvement on its
> own. This structuring also makes it possible to easily skip the last
> commit which adds it as a basic SQL type, or to implement that part
> differently.
>
> But the main function of the separation is to help the review process,
> as some of the syntax extensions are complex, and following them in a
> single patch would be difficult, especially in the incremental parser.
>
> In addition to the tests included in the patches, I also did several
> rounds of AI-assisted validations and long fuzzing runs, validating it
> against other implementations. The corner cases and issues found
> during these runs are now included in the test suite.
>
> [1]: https://postgr.es/m/CAN4CZFNXdKL4eb_GwT_h-vUuUV%2BCbPCk_8-%2BS3kV8iFmNmUw7A%40mail.gmail.com
