Re: A bug when use get_bit() function for a long bytea string
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: A bug when use get_bit() function for a long bytea string |
| Дата | |
| Msg-id | CAG-ACPWfAZhUa7nFCgTg9axW+6udK6k-N=Vwe-JMR7nvx9qQrw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: A bug when use get_bit() function for a long bytea string (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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 по дате отправления: