From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"ashutosh(dot)bapat" <ashutosh(dot)bapat(at)2ndquadrant(dot)com>,"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-04-03 08:53:33 |
Message-ID: | 3ae0e84f-1d80-4f98-b36e-235ebcae4ff6@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
movead(dot)li(at)highgo(dot)ca wrote:
> >I believe the formula for the upper limit in the 32-bit case is:
> > (len <= PG_INT32_MAX / 8) ? (len*8 - 1) : PG_INT32_MAX;
>
> >These functions could benefit from a comment mentioning that
> >they cannot reach the full extent of a bytea, because of the size limit
> >on the bit number.
>
> Because the 2nd argument is describing 'bit' location of every byte in bytea
> string, so an int32 is not enough for that. I think the change is nothing
> wrong,
> or I have not caught your means?
In existing releases, the SQL definitions are set_bit(bytea,int4,int4)
and get_bit(bytea,int4) and cannot be changed to not break the API.
So the patch meant for existing releases has to deal with a too-narrow
int32 bit number.
Internally in the C functions, you may convert that number to int64
if you think it's necessary, but you may not use PG_GETARG_INT64
to pick a 32-bit argument.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2020-04-03 08:54:33 | Re: [PATCH] Keeps tracking the uniqueness with UniqueKey |
Previous Message | Asif Rehman | 2020-04-03 08:45:23 | Re: WIP/PoC for parallel backup |