Proposal: JSON5 support in the JSON parsers
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253082psql -h localhost -U postgresBuilt from patchset v2 (message #2), October 06, 2026 at 08:19 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253082_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253082_2 && git checkout t253082_2Patchset v2 (message #2) is on t253082_2
Hello,
During the prototyping of configuration format proposal[1]/messages/by-id/CAN4CZFNXdKL4eb_GwT_h-vUuUV+CbPCk_8-+S3kV8iFmNmUw7A@mail.gmail.com 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]: /messages/by-id/CAN4CZFNXdKL4eb_GwT_h-vUuUV+CbPCk_8-+S3kV8iFmNmUw7A@mail.gmail.com
Attachments:
t253082_10001-Add-JSON5-comment-support-to-the-JSON-lexer.patchapplication/octet-stream; name=0001-Add-JSON5-comment-support-to-the-JSON-lexer.patchDownload+316-30
0004-Add-JSON5-single-quoted-string-support-to-the-JSON-l.patchapplication/octet-stream; name=0004-Add-JSON5-single-quoted-string-support-to-the-JSON-l.patchDownload+54-9
0005-Add-JSON5-number-extensions-to-the-JSON-lexer.patchapplication/octet-stream; name=0005-Add-JSON5-number-extensions-to-the-JSON-lexer.patchDownload+366-37
0002-Add-JSON5-trailing-comma-support-to-the-JSON-parser.patchapplication/octet-stream; name=0002-Add-JSON5-trailing-comma-support-to-the-JSON-parser.patchDownload+117-3
0003-Add-JSON5-unquoted-object-key-support-to-the-JSON-pa.patchapplication/octet-stream; name=0003-Add-JSON5-unquoted-object-key-support-to-the-JSON-pa.patchDownload+180-20
0006-Add-JSON5-multi-line-string-support-to-the-JSON-lexe.patchapplication/octet-stream; name=0006-Add-JSON5-multi-line-string-support-to-the-JSON-lexe.patchDownload+101-12
0008-Add-json5-type-documentation.patchapplication/octet-stream; name=0008-Add-json5-type-documentation.patchDownload+92-2
0007-Add-json5-data-type-with-cast-paths-to-json-jsonb.patchapplication/octet-stream; name=0007-Add-json5-data-type-with-cast-paths-to-json-jsonb.patchDownload+1130-12
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]/messages/by-id/CAD5tBcJeywJ+-UcedzJfG+fX2EWC_vQXTFVN6_MUFXY9Mebjhw@mail.gmail.com.
* I corrected many corner-case issues compared to v1, mainly based on
more fuzz testing against the json5 reference implementation[2]https://github.com/json5/json5. v2
also passes the official json5-tests[3]https://github.com/json5/json5-tests 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]: /messages/by-id/CAD5tBcJeywJ+-UcedzJfG+fX2EWC_vQXTFVN6_MUFXY9Mebjhw@mail.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:
Show quoted text
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 NaNTo 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]: /messages/by-id/CAN4CZFNXdKL4eb_GwT_h-vUuUV+CbPCk_8-+S3kV8iFmNmUw7A@mail.gmail.com