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

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:

Reply via email to