| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
| Cc: | "Ashutosh Bapat" <ashutosh(dot)bapat(at)2ndquadrant(dot)com>, "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>, "pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: A bug when use get_bit() function for a long bytea string |
| Date: | 2020-03-27 19:19:59 |
| Message-ID: | 20650.1585336799@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
> So aside from the integer overflow bug, isn't there the issue that the
> "offset" argument of get_bit() and set_bit() should have been an
> int8 in the first place?
Good point, but a fix for that wouldn't be back-patchable.
It does suggest that we should just make all the internal logic use int8
for these values (as the solution to the overflow issue), and then in
HEAD only, adjust the function signatures so that int8 can be passed in.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2020-03-27 19:20:27 | Re: backup manifests |
| Previous Message | Sergei Kornilov | 2020-03-27 19:15:50 | Re: Improve handling of parameter differences in physical replication |