Re: Proposal to use JSON for Postgres Parser format - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Proposal to use JSON for Postgres Parser format
Date
Msg-id CAH2-WzmcjVT7BBUHz1kvW-zOgHCEXDvdAGsbNi+r4PqdjWUCdA@mail.gmail.com
Whole thread Raw
In response to Re: Proposal to use JSON for Postgres Parser format  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal to use JSON for Postgres Parser format
List pgsql-hackers
On Mon, Sep 19, 2022 at 9:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> As Munro adduces nearby, it'd be a stretch to conclude that the current
> format was designed with any Postgres-related goals in mind at all.
> I think he's right that it's a variant of some Lisp-y dump format that's
> probably far hoarier than even Berkeley Postgres.

That sounds very much like the 1980s graduate student equivalent of
JSON to my ears.

JSON is generally manipulated as native Javascript/python/whatever
lists, maps, and strings. It's an interchange format that tries not to
be obtrusive in the same way as things like XML always are, at the
cost of making things kinda dicey for things like numeric precision
(unless you can account for everything). Isn't that...basically the
same concept as the lisp-y dump format, at a high level?

> I think the principal mistake in what we have now is that the storage
> format is identical to the "developer friendly" text format (plus or
> minus some whitespace).  First we need to separate those.  We could
> have more than one equivalent text format perhaps, and I don't have
> any strong objection to basing the text format (or one of them) on
> JSON.

Agreed.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: remove more archiving overhead
Next
From: mahendrakar s
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER