On Sun, 4 Dec 2022 at 22:53, Dean Rasheed wrote:
> Ah, I see that you changed the overflow test, and I realise that I
> forgot to answer your question about why I wrote that as 1 - INT_MIN /
> 10 over on the other thread.
>
> The reason is that we need to detect whether tmp * base will exceed
> -I
On Sun, 4 Dec 2022 at 03:19, David Rowley wrote:
>
> Pushed with some small adjustments.
>
Ah, I see that you changed the overflow test, and I realise that I
forgot to answer your question about why I wrote that as 1 - INT_MIN /
10 over on the other thread.
The reason is that we need to detect w
On Sun, 4 Dec 2022 at 13:52, David Rowley wrote:
> Thanks. I'll start looking at the patch again now. If I don't find any
> problems then I'll push it.
Pushed with some small adjustments.
David
On Fri, 2 Dec 2022 at 20:35, Peter Eisentraut
wrote:
> If we are happy with this patch, then it's okay with me if you push this
> first. I'll probably need to do another pass over my patch anyway, so a
> bit more work isn't a problem.
Thanks. I'll start looking at the patch again now. If I don't
On 01.12.22 06:38, David Rowley wrote:
If this was going to cause huge conflicts with Peter's patch then I
might think differently. I feel like it's a fairly trivial task to
rebase.
If the consensus is that we should fix this afterwards, then I'm happy to delay.
If we are happy with this patch
On Thu, 1 Dec 2022 at 05:38, David Rowley wrote:
>
> On Thu, 1 Dec 2022 at 18:27, John Naylor wrote:
> > I don't see why the non-decimal literal patch needs to be "immediately"
> > faster? If doing this first leads to less code churn, that's another
> > consideration, but you haven't made that
On Thu, 1 Dec 2022 at 18:27, John Naylor wrote:
> I don't see why the non-decimal literal patch needs to be "immediately"
> faster? If doing this first leads to less code churn, that's another
> consideration, but you haven't made that argument.
My view is that Peter wants to keep the code he's
On Thu, Dec 1, 2022 at 6:42 AM David Rowley wrote:
>
> I was thinking that we should likely apply this before doing the hex
> literals, which is the main focus of [1]. The reason being is so that
> that patch can immediately have faster conversions by allowing the
> compiler to use bit shifting i
rt, end;
int64 n, e;
char buff[16];
double v1_time, v2_time;
if (argc < 3)
{
n = DEFAULT_START;
e = DEFAULT_END;
}
else
{
n = pg_strtoint32(argv[1]);
e = pg_strtoint32(ar
