Re: [GENERAL] 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