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

From Michel Pelletier
Subject Re: Proposal to use JSON for Postgres Parser format
Date
Msg-id CACxu=vJXTuNYZMMzdF5h48XniV4_2sRUtB=RVKhn+Zip78sYvA@mail.gmail.com
Whole thread Raw
In response to Re: Proposal to use JSON for Postgres Parser format  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: Proposal to use JSON for Postgres Parser format  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers


On Mon, Oct 31, 2022 at 6:15 AM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
On Mon, 31 Oct 2022 at 13:46, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Fri, Oct 28, 2022 at 4:27 PM Andrew Dunstan <andrew@dunslane.net> wrote:
>> On 2022-10-27 Th 19:38, Andres Freund wrote:
>> > Hi,
>> >
>> > On 2022-09-19 22:29:15 -0400, Tom Lane 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.
>> > +1
>>
>> Agreed.
>
> +1
>
> Michel, it seems that you now have a green light to implement node to
> json function.

I think that Tom's proposal that we +1 is on a pg_node_tree to json
SQL function / cast; which is tangentially related to the "nodeToJson
/ changing the storage format of pg_node_tree to json" proposal, but
not the same.

I agree.
 
I will add my +1 to Tom's proposal for that function/cast, but I'm not
sure on changing the storage format of pg_node_tree to json.

I'm going to spike on this function and will get back to the thread with any updates.

Thank you!

-Michel

pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Prefetch the next tuple's memory during seqscans
Next
From: Bharath Rupireddy
Date:
Subject: Re: Adding doubly linked list type which stores the number of items in the list