From: | "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca> |
---|---|
To: | "Ashutosh Bapat" <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, ashutosh(dot)bapat <ashutosh(dot)bapat(at)2ndquadrant(dot)com> |
Subject: | Re: Re: A bug when use get_bit() function for a long bytea string |
Date: | 2020-03-13 03:18:47 |
Message-ID: | 20200313111842791351178@highgo.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks for the reply.
>Why have you used size? Shouldn't we use int64?
Yes, thanks for the point, I have changed the patch.
>If get_bit()/set_bit() accept the second argument as int32, it can not
>be used to set bits whose number does not fit 32 bits. I think we need
>to change the type of the second argument as well.
Because int32 can cover the length of bytea that PostgreSQL support,
and I have decided to follow your next point 'not use 64bit int for len',
so I think the second argument can keep int32.
>Also, I think declaring len to be int is fine since 1G would fit an
>int, but what does not fit is len * 8, when performing that
>calculation, we have to widen the result. So, instead of changing the
>datatype of len, it might be better to perform the calculation as
>(int64)len * 8. If we use int64, we could also use INT64_FORMAT
>instead of using %ld.
Have followed and changed the patch.
>Since this is a bug it shouldn't wait another commitfest, but still
>add this patch to the commitfest so that it's not forgotten.
Will do.
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
Attachment | Content-Type | Size |
---|---|---|
long_bytea_string_bug_fix_ver2.patch | application/octet-stream | 4.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-03-13 03:46:27 | Re: [PATCH] Erase the distinctClause if the result is unique by definition |
Previous Message | Andres Freund | 2020-03-13 03:13:24 | Re: shared-memory based stats collector |