On Tue, Jul 14, 2026 at 7:27 PM Tristan Partin <[email protected]> wrote:
> On Tue Jul 14, 2026 at 11:18 PM UTC, Zsolt Parragi wrote: > >> What are your thoughts on first starting with support for JSONC? It has > >> no implications other than comments (single-line and multi-line) and > >> trailing commas. We could collaborate and commit that, and then > >> subsequently work on JSON5 support. It should enable the JSON5 support > >> patches to be even smaller than what you posted already. > > > > I also sent my patchset[1] for JSONC/JSON5. I wanted to organize it > > into smaller patches and stress test it before sharing, but I think > > it's in a good enough shape now. > > My logic was similar: the first patch in the series is the JSONC > > support, as that's a feature usable on its own. > > Awesome. I will review and see how they compare against my changes! > > >> Do we want to support JSONC/JSON5 in the incremental parser? My > >> inclination is yes so the parsers are consistent in what they support. > > > > I included it for completeness, but the incremental parser has no real > > user other than the tests, and it's complex. A patch without that > > would be significantly smaller. Most (nearly all) of the corner case > > issues I identified while testing the patch were also in that. > > I was able to get a patch for the incremental parser to support comments > in: > > 1 file changed, 272 insertions(+), 41 deletions(-) > > A patch to the incremental parser to support trailing commas is even > smaller: > > 1 file changed, 87 insertions(+), 1 deletions(-) > > These stats don't include the additional tests. > > > [1]: > https://www.postgresql.org/message-id/CAN4CZFP5dvO4sij414YYG%2B4Hghf3M5m2oPiyR_vNgRj3vhQ_0Q%40mail.gmail.com > > > I'm inclined not to support the incremental parser. From a pure grammar POV it would be doable - you would just need a new parsing table. But I suspect the added complexity for the lexer would be considerable. It's already fairly complex, so that bothers me. Also, what's the use case? The point of the incremental parser is to support handling huge documents like backup manifests. But that's not the use case for JSON5. At least for a first go round I would stick with supporting the RD parser only. Then you can ignore things like partial tokens, It might be worth talking about the data representation of a JSON5 datum. One of my first experiments with claude code was the creation of an extension to support YAML. See <https://github.com/adunstan/pgyaml>. One possibly controversial decision I made was to store the YAML in two formats - original text plus the data as jsonb. That costs you some in storage but makes up for it in allowing you to use the equivalent of jsonb ops, and jsonpath on the data efficiently while being able to get back the original text as well. This could be reasonable for small documents such as configuration settings, which is the main use case I see for YAML (and JSON5). (It also provides methods you convert the YAML to pure jsonb) cheers andrew
