| 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-25 10:15:51 |
| Message-ID: | CAEZATCVKVYFTVtBZgDbxB--uApt2nu3uDLr3oSqm9XsEXtTyZQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 25 Jan 2023 at 09:02, Aleksander Alekseev
<aleksander(at)timescale(dot)com> wrote:
>
> > 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".
>
OK, but the point was that we've just added support for accepting hex
inputs in a particular format, so I think it would be useful if
to_hex() could produce outputs compatible with that.
> > 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).
>
Of course there is. This is easy to code in C using unsigned ints,
without resorting to abs() (yes, I'm aware that abs() is undefined for
INT_MIN).
Regards,
Dean
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2023-01-25 10:57:43 | Re: to_hex() for negative inputs |
| Previous Message | Dean Rasheed | 2023-01-25 09:51:03 | Re: Progress report of CREATE INDEX for nested partitioned tables |