Re: [PATCH v2] Add overflow checks to money type input function - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [PATCH v2] Add overflow checks to money type input function
Date
Msg-id alpine.DEB.2.20.1608251650450.7102@lancre
Whole thread Raw
Responses Re: [PATCH v2] Add overflow checks to money type input function  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hello Peter,

My 0.02€ (not $0.02:-) comments on this patch:

Patch applies and "make check" is ok. I see no issue with the code.

A few comments below.

The regression tests are clearer & commented, it is an improvement.

While you are at it, maybe you could consider adding tests for more 
features, eg ',' skipping and '(' as negative sign:
 SELECT '(1)'::MONEY; SELECT '($123,456.78)'::MONEY;

The code does what it advertises. Note that this patch only tests 
overflows when parsing a string. It does not detect overflows during 
operations.


> The money type input function did not have any overflow checks at all.
> There were some regression tests that purported to check for overflow,
> but they actually checked for the overflow behavior of the int8 type
> before casting to money.  Remove those unnecessary checks and add some
> that actually check the money input function.

I think that the lack of generality of the MONEY type makes it near 
unusable (I do not think that it is the place of the database to 
prettyprint the currency, especially with a '$' sign which happen not to 
be the currency of 95% of the world population, the precision is hardwired 
to 2 figures after the unit, the convention to use '(' for negative 
numbers is rather an anglo-saxon accounting one, ...), so I would not have 
bothered. This type should really be named "DOLLAR" or "USD".

> +    /*
> +     * We accumulate the absolute amount in "value" and then apply the sign at
> +     * the end.  (The sign can appear before or after the digits, so it would
> +     * be more complicated to do otherwise.)  Because of the larger range of
> +     * negative signed integers, we build "value" in the negative and then
> +     * flip the sign at the end,

Argh. A trick!

> catching most-negative-number overflow if
> +     * necessary.
> +     */
> +
>     for (; *s; s++)
>     {
>         /* we look for digits as long as we have found less */
>         /* than the required number of decimal places */
>         if (isdigit((unsigned char) *s) && (!seen_dot || dec < fpoint))
>         {
> -            value = (value * 10) + (*s - '0');
> +            Cash newvalue = (value * 10) - (*s - '0');
> +
> +            if (newvalue / 10 != value)

I would have done "if (newvalue > 0)" because / used to be expensive and 
the overflow materializes as a sign inversion, but I understand Tom 
commented against that, so this is fine.

>     /* round off if there's another digit */
>     if (isdigit((unsigned char) *s) && *s >= '5')
> -        value++;
> +        value--;

Positive/negative trick again. A reminder comment?

> +    if (value > 0)

Trick again...

Ok, this test seems to be necessary just for a min int value that would 
have been badly rounded down by the preceding increment.


> +        ereport(ERROR,
> +                (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
> +                 errmsg("value \"%s\" is out of range for type money",
> +                        str)));
>
>     /* adjust for less than required decimal places */
>     for (; dec < fpoint; dec++)
> -        value *= 10;
> +    {
> +        Cash newvalue = value * 10;
> +
> +        if (newvalue / 10 != value)
> +            ereport(ERROR,
> +                    (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
> +                     errmsg("value \"%s\" is out of range for type money",
> +                            str)));
> +
> +        value = newvalue;
> +    }
>
>     /*
>      * should only be trailing digits followed by whitespace, right paren,
> @@ -247,7 +280,17 @@ cash_in(PG_FUNCTION_ARGS)
>                             str)));
>     }
>
> -    result = value * sgn;
> +    if (sgn > 0)
> +    {
> +        result = -value;

The code looks a little bit strange because of the above negative value 
trick. Maybe there could be a reminder comment?

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: increasing the default WAL segment size
Next
From: Tom Lane
Date:
Subject: Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()