On Fri, Jun 24, 2016 at 2:23 PM, Flavius Anton <f.v.an...@gmail.com> wrote: > 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.
It's not very clear to me from this discussion what you actually want to implement, and I think your chances of implementing it successfully and your chances of getting that committed depend heavily on what you actually intend to do. If you want to implement a new datatype, that can be done as a contrib module and, if it doesn't go into the core distribution, it can always go up on GitHub and people can use it if they like it. If you want to implement a tool for validating JSON documents against a JSON schema, you can just write that as a function in a loadable module and people who want to use it can add a CHECK (json_validate_schema(mycolumn, 'schema or a reference thereunto goes here')) constraint. Again, if core doesn't want it, you can still distribute it and people can use it with unmodified PostgreSQL. And similarly, if you want to convert records from PostgreSQL's native format to some new serialization format, there is precedent with that for JSON and it can all be done as an extension to start. If you do something that touches the wire protocol or adds new formats in which data can be returned to the client, I think your chances of getting that committed to core are extremely low. We don't really like to change the wire protocol, and every time we add some extension to it, the amount of actual use that people get out of it is contingent on all of the various reimplementations of that protocol in various language-specific drivers also being extended to support that same thing. It's not worth going through that kind of hassle very often, and I don't think this would come close to having enough value to make that level of pain worthwhile, given that there are so many other ways of accomplishing the same thing: you can use a function in the query to transform the data before sending it, or you can have the client transform it afterwards. Moreover, if your work doesn't go into core then it's probably going to die on the vine because who wants a modified server version that breaks wire protocol compatibility? I'm not taking any position on the intrinsic value of protocol buffer support beyond the broad statement that I don't personally have any reason care about it. That is, I neither support nor oppose the idea of accepting code that does stuff related to protocol buffers. I am only offering a general opinion that something that can exist as an extension is likely (a) easier to implement, (b) easier to get committed, and (c) still potentially useful if it doesn't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
