Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jLd43-0005Ps-BX for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2020 01:30:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jLd42-00022h-9V for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2020 01:30:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jLd41-00022Z-Vo for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2020 01:30:06 +0000 Received: from sender4-op-o13.zoho.com ([136.143.188.13]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jLd3y-0007kM-RN for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2020 01:30:05 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1586222997; cv=none; d=zohomail.com; s=zohoarc; b=F+7RFFN0ve0CelgVp20j8CPEgoEGNohF2CfZIBUgOUXrUGs2Y/QXn+WIG3EOeqZkq02PNf7pZyp4x8DiVS9rAHO4oOIWE5fR+WBkwFWsiTDmlX7t7XlR1kh66qRoteXrf8RxEZRI1qohqDCOghY8MjIp2RuJp44HG1zr6pJPf0s= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1586222997; h=Content-Type:Cc:Date:From:MIME-Version:Message-ID:References:Subject:To; bh=lsIu+p1ps43N72vbg46MiYHoa7QDhASQkxe58FHRpkg=; b=L0tZQsEtqnGVxB5nPhm96TORfpwVPFUEqLdGZIDPSybP1pseb+LqMYudhJrvAPG4e/aLhitm5FjTRMDMiOtCZQIcEfyYMQG3j9W13vA0WA9yFl5IYxwNlmUon9PRFDky3hO0278sfkzcj99XH1TlQEDZOZL3GPnL8vWbSa1XxMs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=highgo.ca; spf=pass smtp.mailfrom=movead.li@highgo.ca; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1586222997; s=zoho; d=highgo.ca; i=movead.li@highgo.ca; h=Date:From:To:Cc:Subject:References:Mime-Version:Message-ID:Content-Type; bh=lsIu+p1ps43N72vbg46MiYHoa7QDhASQkxe58FHRpkg=; b=bTPHGD1ifjQ6drSwvd/bGDFHC7o3TP+PO6Zt+sc6PhJy63e2XrNsrASTrPTVZR+7 5AVFrJt6iIhDmIAGoCeKIou4+SqwAfr0HUFV7nqs1z3HhGzNwcpODVASktsgawzG8Cg i5Qe/6ubPw8pvY6HhLVO+LzEt2x2DDSLDSVvAnMI= Received: from lchch (124.133.18.218 [124.133.18.218]) by mx.zohomail.com with SMTPS id 1586222993886157.8838527214847; Mon, 6 Apr 2020 18:29:53 -0700 (PDT) Date: Tue, 7 Apr 2020 09:29:51 +0800 From: "movead.li@highgo.ca" To: "Daniel Verite" Cc: "Tom Lane" , ashutosh.bapat , pgsql-hackers Subject: Re: A bug when use get_bit() function for a long bytea string References: <3ae0e84f-1d80-4f98-b36e-235ebcae4ff6@manitou-mail.org> X-Priority: 3 X-GUID: 765F5B15-CBE0-4420-9C4B-AE63CDADD195 X-Has-Attach: no X-Mailer: Foxmail 7.2.14.410[cn] Mime-Version: 1.0 Message-ID: <2020040709294706977061@highgo.ca> Content-Type: multipart/alternative; boundary="----=_001_NextPart451128425578_=----" X-ZohoMailClient: External List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. ------=_001_NextPart451128425578_=---- Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: base64 DQo+SW4gZXhpc3RpbmcgcmVsZWFzZXMsIHRoZSBTUUwgZGVmaW5pdGlvbnMgYXJlIHNldF9iaXQo Ynl0ZWEsaW50NCxpbnQ0KQ0KPmFuZCBnZXRfYml0KGJ5dGVhLGludDQpIGFuZCBjYW5ub3QgYmUg Y2hhbmdlZCB0byBub3QgYnJlYWsgdGhlIEFQSS4NCj5TbyB0aGUgcGF0Y2ggbWVhbnQgZm9yIGV4 aXN0aW5nIHJlbGVhc2VzIGhhcyB0byBkZWFsIHdpdGggYSB0b28tbmFycm93DQo+aW50MzIgYml0 IG51bWJlci4NCiANCj5JbnRlcm5hbGx5IGluIHRoZSBDIGZ1bmN0aW9ucywgeW91IG1heSBjb252 ZXJ0IHRoYXQgbnVtYmVyIHRvIGludDY0DQo+aWYgeW91IHRoaW5rIGl0J3MgbmVjZXNzYXJ5LCBi dXQgeW91IG1heSBub3QgdXNlIFBHX0dFVEFSR19JTlQ2NA0KPnRvIHBpY2sgYSAzMi1iaXQgYXJn dW1lbnQuDQpUaGUgaW5wdXQgcGFyYW1ldGVyIG9mICdzZXRfYml0KCknIGZ1bmN0aW9uIGZvciAn Ynl0ZWFHZXRCaXQnIGhhcyBjaGFuZ2VkDQp0byAgJ2J5dGVhIGludDggaW50NCcsIGJ1dCBtYXli ZSBhbm90aGVyICdzZXRfYml0KCknICBmb3IgJ2JpdGdldGJpdCcgbmVlZCBub3QNCmNoYW5nZWQu IFRoZSBzYW1lIHdpdGggJ2dldF9iaXQoKScuDQoNCg0KDQoNClJlZ2FyZHMsDQpIaWdoZ28gU29m dHdhcmUgKENhbmFkYS9DaGluYS9QYWtpc3RhbikgDQpVUkwgOiB3d3cuaGlnaGdvLmNhIA0KRU1B SUw6IG1haWx0bzptb3ZlYWQoZG90KWxpKGF0KWhpZ2hnbyhkb3QpY2ENCg== ------=_001_NextPart451128425578_=---- Content-Type: text/html; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable =0A

=0A
>In ex= isting releases, the SQL definitions are set_bit(bytea,int4,int4)
>and get_bit(bytea,int4) and cannot be changed to no= t break the API.
>So the patch meant for exi= sting releases has to deal with a too-narrow
>int32 bit number.
 
>Intern= ally in the C functions, you may convert that number to int64
>if you think it's necessary, but you may not use PG_GET= ARG_INT64
>to pick a 32-bit argument.
<= /div>
The input parameter of 'set_bit()' function for 'byteaGetBi= t' has changed
to  'bytea int8 int4', but ma= ybe another 'set_bit()'  for '= bitgetbit' need not
changed. T= he same with 'get_bit()'.


=0A
Regards,
Highgo Software (Canada/China/Pakistan)
UR= L : www.highgo.ca
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
=0A
=0A ------=_001_NextPart451128425578_=------