From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Natalie Wenz <nataliewenz(at)ebureau(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] Insert result does not match record count |
Date: | 2013-07-24 17:48:23 |
Message-ID: | 1892.1374688103@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> writes:
> Also worth mentioning is bug #7766.
> http://www.postgresql.org/message-id/E1Tlli5-0007tR-HO@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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-07-24 18:08:32 | Re: [GENERAL] Insert result does not match record count |
Previous Message | Vik Fearing | 2013-07-24 15:44:58 | Re: [GENERAL] Insert result does not match record count |
From | Date | Subject | |
---|---|---|---|
Next Message | Karol Trzcionka | 2013-07-24 17:49:04 | Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements |
Previous Message | Greg Stark | 2013-07-24 17:42:39 | Re: Review: UNNEST (and other functions) WITH ORDINALITY |