Re: [HACKERS] Insert result does not match record count - Mailing list pgsql-general

From Tom Lane
Subject Re: [HACKERS] Insert result does not match record count
Date
Msg-id 22395.1391204301@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Insert result does not match record count  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] Insert result does not match record count
List pgsql-general
Bruce Momjian <bruce@momjian.us> writes:
> On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote:
>> Unfortunately, I gave up on it as being over my head when I noticed I
>> was changing the protocol itself.  I should have notified the list so
>> someone else could have taken over.

> OK, so that brings up a good question.  Can we change the protocol for
> this without causing major breakage?  Tom seems to indicate that it can
> be done for 9.4, but I thought protocol breakage was a major issue.  Are
> we really changing the wire protocol here, or just the type of string we
> can pass back to the interface?

What I said about it upthread was "this is effectively a protocol change,
albeit a pretty minor one, so I can't see back-patching it".

The discussion in bug #7766 shows that some client-side code is likely to
need fixing, and that such fixing might actually be nontrivial for them.
So changing this in a minor release is clearly a bad idea.  But I don't
have a problem with widening the counters in a major release where we
can document it as a potential compatibility issue.

I took a quick look and noted that CMDSTATUS_LEN and
COMPLETION_TAG_BUFSIZE are set to 64, and have been for quite a long time,
so command status string buffer sizes should not be a problem.

I think we probably just need to widen es_processed and touch related
code.  Not sure what else Vik saw that needed doing.

            regards, tom lane


pgsql-general by date:

Previous
From: Raymond O'Donnell
Date:
Subject: Re: Info
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Insert result does not match record count