On Fri, Oct 01, 2021 at 07:56:33AM +0100, Dean Rasheed wrote:
> On Thu, 30 Sept 2021 at 18:25, Jaime Casanova
> wrote:
> >
> > Are you planning to commit this soon?
> >
>
> Yes, I'll take a look at it next week.
>
Hi Dean,
Great! I'll move the CF entry to the Next Commitfest so we can move to
On Thu, 30 Sept 2021 at 18:25, Jaime Casanova
wrote:
>
> Are you planning to commit this soon?
>
Yes, I'll take a look at it next week.
I think it's worth backpatching, despite the fact that it's a pretty
obscure corner case that probably isn't affecting anyone -- similar
fixes in this area
On Mon, Sep 13, 2021 at 07:29:13PM +0100, Dean Rasheed wrote:
> On Mon, 13 Sept 2021 at 17:51, Alvaro Herrera wrote:
> >
> > I came here just to opine that there should be a comment about there not
> > being a clamp to the maximum scale. For example, log_var says "Set the
> > scales .. so that
On Mon, 13 Sept 2021 at 17:51, Alvaro Herrera wrote:
>
> I came here just to opine that there should be a comment about there not
> being a clamp to the maximum scale. For example, log_var says "Set the
> scales .. so that they each have more digits ..." which seems clear
> enough; I think the
On 2021-Sep-12, Dean Rasheed wrote:
> So the fix is just to remove the upper bound on this local_rscale, as
> we do for the full-precision calculation. This doesn't impact
> performance, because it's only computing the logarithm to 8
> significant digits at this stage, and when x is very close to
On Thu, Sep 02, 2021 at 07:27:09AM +0100, Dean Rasheed wrote:
>
> It's mostly done, but there is one more corner case where it loses
> precision. I'll post an update shortly.
>
I spent some more time looking at this, testing a variety of edge
cases, and the only case I could find that produces
On Thu, Sep 02, 2021 at 07:27:09AM +0100, Dean Rasheed wrote:
> On Thu, 2 Sept 2021 at 00:39, Jaime Casanova
> wrote:
> >
> > Hi Dean,
> >
> > It seems you already committed this. But it's still as "Ready for
> > committer" in the commitfest app.
> >
> > Are we waiting for something else or we
On Thu, 2 Sept 2021 at 00:39, Jaime Casanova
wrote:
>
> Hi Dean,
>
> It seems you already committed this. But it's still as "Ready for
> committer" in the commitfest app.
>
> Are we waiting for something else or we can mark it as committed?
>
It's mostly done, but there is one more corner case
On Fri, Aug 06, 2021 at 09:27:03PM +0100, Dean Rasheed wrote:
> On Fri, 6 Aug 2021 at 21:26, Tom Lane wrote:
> >
> > Dean Rasheed writes:
> > > On Fri, 6 Aug 2021 at 17:15, Tom Lane wrote:
> > >> Looks plausible by eyeball (I've not tested).
> >
> > > So, I have back-branch patches for this
On Fri, 6 Aug 2021 at 21:26, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Fri, 6 Aug 2021 at 17:15, Tom Lane wrote:
> >> Looks plausible by eyeball (I've not tested).
>
> > So, I have back-branch patches for this ready to go. The question is,
> > is it better to push now, or wait until after
Dean Rasheed writes:
> On Fri, 6 Aug 2021 at 17:15, Tom Lane wrote:
>> Looks plausible by eyeball (I've not tested).
> So, I have back-branch patches for this ready to go. The question is,
> is it better to push now, or wait until after next week's releases?
I'd push now, given we have a
On Fri, 6 Aug 2021 at 17:15, Tom Lane wrote:
>
> > I guess the best thing to do is just test the value against
> > PG_INT32_MIN/MAX, which is what int84() does. There are 2 other places
> > in numeric.c that use similar code to check for int16/32 overflow, so
> > it's possible that they're broken
Dean Rasheed writes:
> So the "test for overflow by reverse-conversion" obviously isn't
> working as intended, and it's going through power_var_int() when it
> shouldn't. I don't think there's anything wrong with that code, so I
> think this is a compiler bug.
Yeah, looks like one.
> I guess
On Fri, 6 Aug 2021 at 03:58, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Thu, 5 Aug 2021 at 17:04, Tom Lane wrote:
> >> It looks like castoroides is not happy with this patch:
> >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides=2021-08-01%2008%3A52%3A43
>
> > Hmm,
Dean Rasheed writes:
> On Thu, 5 Aug 2021 at 17:04, Tom Lane wrote:
>> It looks like castoroides is not happy with this patch:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides=2021-08-01%2008%3A52%3A43
> Hmm, there's something very weird going on there.
Yeah. I tried to
On Thu, 5 Aug 2021 at 17:04, Tom Lane wrote:
>
> It looks like castoroides is not happy with this patch:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides=2021-08-01%2008%3A52%3A43
>
> Maybe there's some hidden C99 dependency in what you did?
> Although pademelon, which is
Dean Rasheed writes:
> On Thu, 22 Jul 2021 at 16:19, Dean Rasheed wrote:
>> Thanks for looking. Barring any further comments, I'll push this in a few
>> days.
> So I have been testing this a lot over the last couple of days, and I
> have concluded that the patch works well as far as it goes,
On Thu, 22 Jul 2021 at 16:19, Dean Rasheed wrote:
>
> On Thu, 22 Jul 2021 at 06:13, Yugo NAGATA wrote:
> >
> > Thank you for updating the patch. I am fine with the additional comments.
> > I don't think there is any other problem left, so I marked it
> > Ready-for-Committers.
>
> Thanks for
On Thu, 22 Jul 2021 at 06:13, Yugo NAGATA wrote:
>
> Thank you for updating the patch. I am fine with the additional comments.
> I don't think there is any other problem left, so I marked it
> Ready-for-Committers.
>
Thanks for looking. Barring any further comments, I'll push this in a few
On Wed, 21 Jul 2021 11:10:16 +0100
Dean Rasheed wrote:
> On Tue, 20 Jul 2021 at 10:17, Yugo NAGATA wrote:
> >
> > This patch fixes numeric_power() to handle negative bases correctly and not
> > to raise an error "cannot take logarithm of a negative number", as well as a
> > bug that a result
On Tue, 20 Jul 2021 at 10:17, Yugo NAGATA wrote:
>
> This patch fixes numeric_power() to handle negative bases correctly and not
> to raise an error "cannot take logarithm of a negative number", as well as a
> bug that a result whose values is almost zero is incorrectly returend as 1.
> The
On Wed, 7 Jul 2021 18:36:56 +0100
Dean Rasheed wrote:
> On Thu, 1 Jul 2021 at 14:17, Dean Rasheed wrote:
> >
> > On Tue, 29 Jun 2021 at 12:08, Dean Rasheed wrote:
> > >
> > > Numeric x^y is supported for x < 0 if y is an integer, but this
> > > currently fails if y is outside the range of an
On Wed, 7 Jul 2021 at 18:57, Zhihong Yu wrote:
>
> + (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
> +errmsg("value overflows numeric format")));
>
> Here is an example of existing error message which I think is more readable
> than 'overflows numeric
On Wed, Jul 7, 2021 at 10:37 AM Dean Rasheed
wrote:
> On Thu, 1 Jul 2021 at 14:17, Dean Rasheed
> wrote:
> >
> > On Tue, 29 Jun 2021 at 12:08, Dean Rasheed
> wrote:
> > >
> > > Numeric x^y is supported for x < 0 if y is an integer, but this
> > > currently fails if y is outside the range of an
On Thu, 1 Jul 2021 at 14:17, Dean Rasheed wrote:
>
> On Tue, 29 Jun 2021 at 12:08, Dean Rasheed wrote:
> >
> > Numeric x^y is supported for x < 0 if y is an integer, but this
> > currently fails if y is outside the range of an int32
>
> I've been doing some more testing of this, and I spotted
On Tue, 29 Jun 2021 at 12:08, Dean Rasheed wrote:
>
> Numeric x^y is supported for x < 0 if y is an integer, but this
> currently fails if y is outside the range of an int32
>
I've been doing some more testing of this, and I spotted another
problem with numeric_power().
This is what happens
Numeric x^y is supported for x < 0 if y is an integer, but this
currently fails if y is outside the range of an int32:
SELECT (-1.0) ^ 2147483647;
?column?
-
-1.
(1 row)
SELECT (-1.0) ^ 2147483648;
ERROR: cannot take logarithm of a negative number
27 matches
Mail list logo
