Re: A bug when use get_bit() function for a long bytea string

From: Ashutosh Bapat <ashutosh(dot)bapat(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: A bug when use get_bit() function for a long bytea string
Date: 2020-03-26 17:10:57
Message-ID: CAG-ACPWfAZhUa7nFCgTg9axW+6udK6k-N=Vwe-JMR7nvx9qQrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 26 Mar 2020 at 19:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ashutosh Bapat <ashutosh(dot)bapat(at)2ndquadrant(dot)com> writes:
> > On Wed, 18 Mar 2020 at 08:18, movead(dot)li(at)highgo(dot)ca <movead(dot)li(at)highgo(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-03-26 17:39:52 Re: plan cache overhead on plpgsql expression
Previous Message Alexey Kondratov 2020-03-26 17:09:15 Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly