From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal to use JSON for Postgres Parser format |
Date: | 2022-09-20 03:25:16 |
Message-ID: | CAH2-WznFVmaYqmRck-t27MN6=g7iO-Y8VbXkDuUECEBYnjm2jA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 19, 2022 at 7:29 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2022-09-20 03:32:38 | Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures |
Previous Message | Michael Paquier | 2022-09-20 03:21:15 | Re: Support pg_attribute_aligned and noreturn in MSVC |