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

From Ashutosh Bapat
Subject Re: A bug when use get_bit() function for a long bytea string
Date
Msg-id CAG-ACPWfAZhUa7nFCgTg9axW+6udK6k-N=Vwe-JMR7nvx9qQrw@mail.gmail.com
Whole thread Raw
In response to Re: A bug when use get_bit() function for a long bytea string  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-hackers by date:

Previous
From: Alexey Kondratov
Date:
Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly
Next
From: Tom Lane
Date:
Subject: Re: plan cache overhead on plpgsql expression