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

On 02/01/2014 02:26 AM, Bruce Momjian wrote:
> On Sat, Feb 1, 2014 at 02:25:16AM +0100, Vik Fearing wrote:
>>> 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.
>> Unfortunately, I just did some cleanup last week and removed that
>> branch. Had I waited a bit more I still would have had all the work I
>> had done. I'll see how quickly I can redo it to get to the part where I
>> got scared of what I was doing.
>>
>> It will have to wait until next week though; I am currently at FOSDEM.
> OK, thanks. I thought it only required passing the int64 around until
> it got into the string passed to the client. The original patch is in
> the email archives if you want it.

The original patch didn't have much in the way of actual work done,
unfortunately.

Without re-doing the work, my IRC logs show that I was bothered by this
in src/backend/tcop/postgres.c:

case 'E': /* execute */
{
const char *portal_name;
int max_rows;

forbidden_in_wal_sender(firstchar);

/* Set statement_timestamp() */
SetCurrentStatementStartTimestamp();

portal_name = pq_getmsgstring(&input_message);
max_rows = pq_getmsgint(&input_message, 4);
pq_getmsgend(&input_message);

exec_execute_message(portal_name, max_rows);
}
break;

I needed to change max_rows to int64 which meant I had to change
pq_getmsgint to pq_getmsgint64 which made me a little worried. I was
already overwhelmed by how much code I was changing and this one made me
reconsider.

If it's just a n00b thing, I guess I can pick this back up for 9.5.

--
Vik