| From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dave Page <dpage(at)pgadmin(dot)org> |
| Subject: | Re: Numeric x^y for negative x |
| Date: | 2021-08-06 20:23:39 |
| Message-ID: | CAEZATCWru3VbPCu8P=YD0k3KaSfg7TQ=Osyq43Hz8k6pnQwFCg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 6 Aug 2021 at 17:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 in the same way on that platform,
> > but they aren't covered by the regression tests, so it's also possible
> > that they're OK. Anyway, something like the attached seems likely to
> > be safer.
>
> 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?
Regards,
Dean
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-08-06 20:25:02 | Re: Alias collision in `refresh materialized view concurrently` |
| Previous Message | Tom Lane | 2021-08-06 19:17:28 | Re: OpenSSL 3.0.0 compatibility |