Re: A bug when use get_bit() function for a long bytea string
Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>
From: Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "movead.li@highgo.ca" <movead.li@highgo.ca>,
pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-03-26T17:10:57Z
Lists: pgsql-hackers
On Thu, 26 Mar 2020 at 19:39, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com> writes: > > On Wed, 18 Mar 2020 at 08:18, movead.li@highgo.ca <movead.li@highgo.ca> > > wrote: > >> if we change return type of all those functions to int64, we won't need > >> this cast. > >> I change the 'encode' function, it needs an int64 return type, but keep > >> other > >> functions in 'pg_encoding', because I think it of no necessary reason. > > > Ok, let's leave it for a committer to decide. > > If I'm grasping the purpose of these correctly, wouldn't Size or size_t > be a more appropriate type? Andy had used Size in his earlier patch. But I didn't understand the reason behind it and Andy didn't give any reason. From the patch and the code around the changes some kind of int (so int64) looked better. But if there's a valid reason for using Size, I am fine with it too. Do we have a SQL datatype corresponding to Size? -- Best Wishes, Ashutosh
Commits
-
Adjust bytea get_bit/set_bit to cope with bytea strings > 256MB.
- e40c4d4914fd 9.6.18 landed
- dbb121038c74 9.5.22 landed
- 889786e0e8c1 10.13 landed
- 6e6b74a206c3 12.3 landed
- 5d79fc60c57d 11.8 landed
-
Adjust bytea get_bit/set_bit to use int8 not int4 for bit numbering.
- 26a944cf29ba 13.0 landed