On Mon, Sep 19, 2022 at 7:29 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Maybe a compromise could be found whereby we provide a conversion > function that converts whatever the catalog storage format is to > some JSON equivalent. That would address the needs of external > code that doesn't want to write a custom parser, while not tying > us directly to JSON.
That seems like a perfectly good solution, as long as it can be done in a way that doesn't leave consumers of the JSON output at any kind of disadvantage. I find the current node tree format ludicrously verbose, and generally hard to work with. But it's not the format itself, really -- that's not the problem. The underlying data structures are typically very information dense. So having an output format that's a known quantity sounds very valuable to me. Writing declarative @> containment queries against (say) a JSON variant of node tree format seems like it could be a huge quality of life improvement. It will make the output format even more verbose, but that might not matter in the same way as it does right now. -- Peter Geoghegan
