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

From Thomas Munro
Subject Re: Proposal to use JSON for Postgres Parser format
Date
Msg-id CA+hUKGKOac5-wW4ofGB9uNZgm2X5wLagQYeTggE2P6Qf=F0-Vg@mail.gmail.com
Whole thread Raw
In response to Re: Proposal to use JSON for Postgres Parser format  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Tue, Sep 20, 2022 at 4:58 PM Peter Geoghegan <pg@bowt.ie> wrote:
> 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.

Yeah.  Easy data interchange on Lisp systems is built in, just write
objects into a socket/file/whatever and read them back, as people now
do with JSON/XML/whatever.  That's the format we see here.

> 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?

Yes, s-expressions and JSON are absolutely the same concept; simple
representation of simple data structures of a dynamically typed
language.  There's even a chain of events connecting the two: JSON is
roughly the literal data syntax from Javascript's grammar, and
Javascript is the language that Brendan Eich developed after Netscape
hired him to do an embedded Lisp (Scheme) for the browser, except they
decided at some point to change tack and make their new language have
a surface grammar more like Java, the new hotness.  If the goal was to
make sure it caught on, it's hard to conclude they were wrong...



pgsql-hackers by date:

Previous
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Data is copied twice when specifying both child and parent table in publication
Next
From: Peter Geoghegan
Date:
Subject: Re: Making C function declaration parameter names consistent with corresponding definition names