Re: A bug when use get_bit() function for a long bytea string
От | Daniel Verite |
---|---|
Тема | Re: A bug when use get_bit() function for a long bytea string |
Дата | |
Msg-id | 9087da0f-f048-4cd3-a55c-1c03adea5a02@manitou-mail.org обсуждение исходный текст |
Ответ на | Re: A bug when use get_bit() function for a long bytea string (Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>) |
Ответы |
Re: A bug when use get_bit() function for a long bytea string
|
Список | pgsql-hackers |
Ashutosh Bapat wrote: > I think we need a similar change in byteaGetBit() and byteaSetBit() > as well. get_bit() and set_bit() as SQL functions take an int4 as the "offset" argument representing the bit number, meaning that the maximum value that can be passed is 2^31-1. But the maximum theorical size of a bytea value being 1 gigabyte or 2^30 bytes, the real maximum bit number in a bytea equals 2^33-1 (2^33=8*2^30), which doesn't fit into an "int4". As a result, the part of a bytea beyond the first 256MB is inaccessible to get_bit() and set_bit(). 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? Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
В списке pgsql-hackers по дате отправления: