Re: Proposal to use JSON for Postgres Parser format

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Proposal to use JSON for Postgres Parser format
Дата
Msg-id CAH2-WzmcjVT7BBUHz1kvW-zOgHCEXDvdAGsbNi+r4PqdjWUCdA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal to use JSON for Postgres Parser format  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proposal to use JSON for Postgres Parser format  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: remove more archiving overhead
Следующее
От: mahendrakar s
Дата:
Сообщение: Re: [PoC] Federated Authn/z with OAUTHBEARER