Re: Proposal to use JSON for Postgres Parser format

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

In response to

Responses

Browse pgsql-hackers by date

  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