Re: [HACKERS] Insert result does not match record count

On Fri, Jan 31, 2014 at 04:38:21PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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.

OK, thanks for the feedback. I understand now. The contents of the
string will potentially have a larger integer, but the byte length of
the string in the wire protocol doesn't change.

Let's wait for Vik to reply and I think we can move forward.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +