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,

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;


                    /* Set statement_timestamp() */

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

                    exec_execute_message(portal_name, max_rows);

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

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


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to