On Wed, 25 Jan 2023 at 09:02, Aleksander Alekseev <aleksan...@timescale.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
