From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Subject: | Re: to_hex() for negative inputs |
Date: | 2023-01-25 09:02:11 |
Message-ID: | CAJ7c6TOKesxF3ReJ+GoBRdM2tHr5X=TLRxM5SDgvXaNQgtmFkg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Dean,
> I don't see how a couple of extra arguments will expand to hundreds.
Maybe I was exaggerating, but the point is that adding extra flags for
every possible scenario is a disadvantageous approach in general.
There is no need to increase the code base, the amount of test cases
and the amount of documentation every time someone has an idea "in
rare cases I also may want to do A or B, let's add a flag for this".
> 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
I'm afraid the behavior of something like to_hex(X, with_sign => true)
is going to be exactly the same. There is no safe and consistent way
to calculate abs(INT_MIN).
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-01-25 09:03:51 | Re: heapgettup() with NoMovementScanDirection unused in core? |
Previous Message | Andres Freund | 2023-01-25 08:52:23 | Re: plpython vs _POSIX_C_SOURCE |