| From: | "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca> |
|---|---|
| To: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
| 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-07 01:29:51 |
| Message-ID: | 2020040709294706977061@highgo.ca |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>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.
The input parameter of 'set_bit()' function for 'byteaGetBit' has changed
to 'bytea int8 int4', but maybe another 'set_bit()' for 'bitgetbit' need not
changed. The same with 'get_bit()'.
Regards,
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-04-07 01:46:14 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
| Previous Message | Kyotaro Horiguchi | 2020-04-07 01:29:09 | Re: Don't try fetching future segment of a TLI. |