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 3.0, the server responds with
> a Server
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 be able to differentiate
version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH
- version compatibility)
> 1. The client sends a StartupMessage 3.x for version 3.x. We could bump the
> version explicitly, or perhaps we should just coin a version of libpq for
> every server release; e.g. whatever PostgreSQL 11
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
> getting at here. I agree w
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 message. That'll only happen w
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 ServerProtocolVersion (or ParameterStatus) message that
>>> server had i
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 ignored those options and could respond as it saw f
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 the correct text
encodin
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, though.
- Startup["Prot
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 sending some new message (let's say,
>> Negotiat
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 highest protocol version
11 matches
Mail list logo