Re: Backend protocol wanted features

Well we would be adding messages that current protocol handlers may not
know how to deal with which will likely require them to rewrite their code.
That being said it would be easier to define a new protocol, even if it is
just an extension and then older clients can still deal with the current
protocol, and newer clients can request the newer protocol.

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

On 29 December 2015 at 16:19, Kevin Wooten <kdubb(at)me(dot)com> wrote:

> Ok well if you define as new protocol as any change, regardless of
> backwards compatibility, then yes. I would define a “new protocol” as
> something that has breaking changes with a previous version or at the very
> least a known deviation from existing behavior.
>
> Extending the protocol with some “well-defined” notifications (using the
> system that is already well-defined) is not something I would consider a
> new protocol.
>
> I guess like you suggested we’re talking about the semantics of a “3.1”
> versus “4.0”. I’m looking for mostly “3.1” type of stuff.
>
> > On Dec 29, 2015, at 2:08 PM, Vladimir Sitnikov <
> sitnikov(dot)vladimir(at)gmail(dot)com> wrote:
> >
> >> So maybe they all are fairly easily implementable in the current
> protocol?
> >
> > New messages => new protocol.
> >
> > For instance "schema_notification" message need to be well-defined,
> > thus it deserves its own entry in the protocol documentation.
> > Doesn't it?
> > Vladimir
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>