On Thu, 26 Mar 2020 at 19:39, Tom Lane <t...@sss.pgh.pa.us> wrote: > Ashutosh Bapat <ashutosh.ba...@2ndquadrant.com> writes: > > On Wed, 18 Mar 2020 at 08:18, movead...@highgo.ca <movead...@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
