From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: to_hex() for negative inputs |
Date: | 2023-01-24 15:10:30 |
Message-ID: | CAEZATCUE04jLA_+-i80arv4D7H03nKTnEm-H_L7wOXHxTWTNmQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 24 Jan 2023 at 13:43, Aleksander Alekseev
<aleksander(at)timescale(dot)com> wrote:
>
> Adding extra arguments for something the user can implement
> (him/her)self doesn't seem to be a great idea. With this approach we
> may end up with hundreds of arguments one day.
>
I don't see how a couple of extra arguments will expand to hundreds.
> =# select case when sign(x) > 0 then '' else '-' end || to_hex(abs(x))
> from ( values (123), (-123) ) as s(x);
>
Which is broken for INT_MIN:
select case when sign(x) > 0 then '' else '-' end || to_hex(abs(x))
from ( values (-2147483648) ) as s(x);
ERROR: integer out of range
Part of the reason for implementing this in core would be to save
users from such easy-to-overlook bugs.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-24 15:13:23 | Re: Improve GetConfigOptionValues function |
Previous Message | Vladimir Sitnikov | 2023-01-24 15:03:51 | Re: run pgindent on a regular basis / scripted manner |