Re: Protocol buffer support for Postgres
От | Flavius Anton |
---|---|
Тема | Re: Protocol buffer support for Postgres |
Дата | |
Msg-id | CANXdjjZsg=-P2B7ZERUyDrKG=1pWVt=6+SgHv1aTDYNVc2S7zQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Protocol buffer support for Postgres (Álvaro Hernández Tortosa <aht@8kdata.com>) |
Список | pgsql-hackers |
On Fri, Jun 24, 2016 at 11:35 AM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote: > > > On 24/06/16 14:23, Flavius Anton wrote: >> >> On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton <f.v.anton@gmail.com> >> wrote: >>> >>> On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark <stark@mit.edu> wrote: >>>> >>>> On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton <f.v.anton@gmail.com> >>>> wrote: >>>>> >>>>> I'd love to talk more about this. >>>> >>>> I thought quite a bit about this a few years ago but never really >>>> picked up it to work on. >> >> Any other thoughts on this? My guess is that it might be an important >> addition to Postgres that can attract even more users, but I am not >> sure if there's enough interest from the community. If I want to pick >> this task, how should I move forward? Do I need to write a design >> document or similar or should I come up with a patch that implements a >> draft prototype? I am new to this community and don't know the code >> yet, so I'd appreciate some guidance from an older, more experienced >> member. >> >> > > Other than protobuf, there are also other serialization formats that > might be worth considering. Not too long ago I suggested working > specifically on serialization formas for the json/jsonb types: > https://www.postgresql.org/message-id/56CB8A62.40100%408kdata.com I believe > this effort is on the same boat. Sure, there are a bunch of these, some of the most popular being: * Cap'n Proto * Flatbuffers * Thrift A longer list is already made here[1]. Meanwhile, I came across another interesting idea. What if, for starters, we don't introduce a completely new serialization format, like Protocol Buffers, but rather make the JSON support more stronger and interesting. What I am thinking is to have a JSON schema (optionally) associated with a JSON column. In this way, you don't have to store the keys on disk anymore and also you'd have your database check for JSON validity at INSERT time. I think there are two big advantages here. What do you think about this one? -- Flavius [1] https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats
В списке pgsql-hackers по дате отправления: