On 2013-07-24 13:48:23 -0400, Tom Lane wrote: > Vik Fearing <vik.fear...@dalibo.com> writes: > > Also worth mentioning is bug #7766. > > http://www.postgresql.org/message-id/e1tlli5-0007tr...@wrigleys.postgresql.org > > Yeah, did you read that whole thread? The real issue here is going to > be whether client-side code falls over on wider-than-32-bit counts. > We can fix the backend and be pretty sure that we've found all the > relevant places inside it, but we'll just be exporting the issue.
> I did look at libpq and noted that it doesn't seem to have any internal > problem, because it returns the count to callers as a string (!). > But what do you think are the odds that callers are using code that > won't overflow? I'd bet on finding atoi() or suchlike in a lot of > callers. Even if they thought to use strtoul(), unsigned long is > not necessarily 64 bits wide. Application code that relies on the values already has problems though since the returned values are pretty bogus now. Including the fact that it can return 0 as the number of modified rows which is checked for more frequently than the actual number IME... So I think client code that uses simplistic stuff like atoi isn't worse off afterwards since the values will be about as bogus. I am more worried about code that does range checks like java's string conversion routines... I think fixing this for 9.4 is fine, but due to the compat issues I think it's to late for 9.3. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
