Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Thu, Jun 29, 2017 at 7:29 PM, Satyanarayana Narlapuram wrote: > -Original Message- The formatting of this message differs from the style normally used on this mailing list, and is hard to read. > 2. If the client version is anything other than

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 20:18, Robert Haas wrote: > I'm not sure if non-critical is exactly the right terminology. What > we want to do is distinguish between things that are intended as > protocol-level options vs. things that are intended as GUCs. We probably also need to

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

x.net>; Magnus Hagander <mag...@hagander.net>; PostgreSQL-development <pgsql-hackers@postgresql.org> Subject: Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility) > 1. The client sends a StartupMessage 3.x for version 3.x. We cou

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Wed, Jun 28, 2017 at 10:27 PM, Tom Lane wrote: > Yeah. Back in the day I helped design the PNG image format, and one > of the better ideas in it was to make a distinction between critical and > noncritical chunks within a PNG file; that was exactly the idea you're >

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 12:23, Craig Ringer wrote: > It does. But I don't see anywhere that extra round trips have been discussed. Ah, right, they're implied by having the server respond with some downversion message and ignore input until the client sends a new startup

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 10:27, Tom Lane wrote: > Craig Ringer writes: >> On 29 June 2017 at 03:01, Robert Haas wrote: >>> It wouldn't be >>> so bad if unrecognized parameters were just ignored; the client would >>> know from the

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

Craig Ringer writes: > On 29 June 2017 at 03:01, Robert Haas wrote: >> It wouldn't be >> so bad if unrecognized parameters were just ignored; the client would >> know from the ServerProtocolVersion (or ParameterStatus) message that >> server had

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 09:44, Craig Ringer wrote: > I > can't personally think of much right away that wouldn't work pretty > well in a follow-on message. Actually, I take that back, there's one thing that's bugged me for a while that wouldn't work well this way: determining

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 03:01, Robert Haas wrote: > One problem with that is that it means that the format of the > StartupMessage itself can never change, which I think is not a good > choice. The startup message could be immediately followed by another supplemental message,

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Wed, Jun 28, 2017 at 1:47 PM, Tom Lane wrote: > Robert Haas writes: >> Here's my proposal: > >> - If the server receives a StartupMessage for v3.x where x > the >> version it knows, instead of just slamming the connection shut, it >> responds by

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

Robert Haas writes: > Here's my proposal: > - If the server receives a StartupMessage for v3.x where x > the > version it knows, instead of just slamming the connection shut, it > responds by sending some new message (let's say, > NegotiateProtocolVersion) specifying the

protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Mon, Mar 28, 2011 at 7:07 PM, Tom Lane wrote: > I wrote: >> Now if we had a track record showing that we could tweak the protocol >> version without causing problems, it'd be fine with me to do it for this >> usage. But we don't, and this particular case doesn't seem like