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 04:58:16 |
Message-ID: | CAH2-WzmcjVT7BBUHz1kvW-zOgHCEXDvdAGsbNi+r4PqdjWUCdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 19, 2022 at 9:48 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | mahendrakar s | 2022-09-20 05:03:10 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Previous Message | Noah Misch | 2022-09-20 04:52:18 | Re: remove more archiving overhead |