Re: [Tarantool-patches] [PATCH v1 1/1] sql: fix comparison between DECIMAL and big DOUBLE

[Timur Safin via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

> From: imeevma@tarantool.org <imeevma@tarantool.org>
> Subject: [PATCH v1 1/1] sql: fix comparison between DECIMAL and big
> DOUBLE
> 
> This patch fixes comparison between DECIMAL value and DOUBLE values
> greater or equal to 1e38 or less or equal to -1e38. Now any DOUBLE
> value
> greater or equal to 1e38 is more than any DECIMAL value and DOUBLE
> value less or equal to -1e38 is less than any DECIMAL value.
> 
> Closes #6376
...
> diff --git a/changelogs/unreleased/gh-6376-fix-incorrect-dec-inf-
> cmp.md b/changelogs/unreleased/gh-6376-fix-incorrect-dec-inf-cmp.md
> new file mode 100644
> index 000000000..70de655f1
> --- /dev/null
> +++ b/changelogs/unreleased/gh-6376-fix-incorrect-dec-inf-cmp.md
> @@ -0,0 +1,3 @@
> +## bugfix/sql
> +
> +* Fixed wrong comparison between DECIMAL and large DOUBLE values
> (gh-6376).
> diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c
> index 4c40f15dc..a3ab31af5 100644
> --- a/src/box/sql/mem.c
> +++ b/src/box/sql/mem.c
> @@ -2451,9 +2451,9 @@ mem_cmp_num(const struct Mem *a, const struct
> Mem *b)
>  		}
>  		case MEM_TYPE_DOUBLE: {
>  			if (b->u.r >= 1e38)
> -				return 1;
> -			if (b->u.r <= -1e38)
>  				return -1;
> +			if (b->u.r <= -1e38)
> +				return 1;

Well, while we are here. I do understand that these kind of constants
already spreading all corners of mem.c when you deal with decimals,
but it's not entirely clear that this all about DECIMAL_MAX_DIGITS
limitation in our decimal implementation. 
And beyond all of that - hardcoded constant are evil. Could you please
introduce any symbolic constant defines for such DECIMAL_MAX_DIGITS-
derivative values? And use them wherever possible.

(I'm not insisting on fixing whole mem.c, that might be done separately,
but at least this tricky case worth it)

>  			decimal_t dec;
>  			decimal_t *d = decimal_from_double(&dec, b->u.r);
>  			assert(d != NULL && d == &dec);

Thanks,
Timur