Re: A bug when use get_bit() function for a long bytea string - Mailing list pgsql-hackers

From movead.li@highgo.ca
Subject Re: A bug when use get_bit() function for a long bytea string
Date
Msg-id 2020040709294706977061@highgo.ca
Whole thread Raw
In response to Re: A bug when use get_bit() function for a long bytea string  ("Daniel Verite" <daniel@manitou-mail.org>)
List 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

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Don't try fetching future segment of a TLI.
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)