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 по дате отправления:

Предыдущее
От: Alexey Kondratov
Дата:
Сообщение: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly
Следующее
От: Tom Lane
Дата:
Сообщение: Re: plan cache overhead on plpgsql expression