Re: simple division - Mailing list pgsql-general

From Tom Lane
Subject Re: simple division
Date
Msg-id 31281.1544023369@sss.pgh.pa.us
Whole thread Raw
In response to Re: simple division  (Geoff Winkless <pgsqladmin@geoff.dj>)
Responses Re: simple division  (Martin Mueller <martinmueller@northwestern.edu>)
List pgsql-general
Geoff Winkless <pgsqladmin@geoff.dj> writes:
> IMO it's fundamentally broken that SQL doesn't cast the result of a
> divide into a numeric value - the potential for unexpected errors
> creeping into calculations is huge; however that's the standard and
> no-one's going to change it now.
> Having said that it's worth noting that those in the Other Place think
> that it's broken enough to go against the standard (they have a DIV b
> for integer divide and a/b for float).

Well, this isn't really blame-able on the SQL standard; it's a
Postgres-ism.  What the spec says (in SQL99, 6.26 <numeric value
expression>) is

         1) If the declared type of both operands of a dyadic arithmetic
            operator is exact numeric, then the declared type of the
            result is exact numeric, with precision and scale determined
            as follows:

            a) Let S1 and S2 be the scale of the first and second operands
              respectively.

            b) The precision of the result of addition and subtraction is
              implementation-defined, and the scale is the maximum of S1
              and S2.

            c) The precision of the result of multiplication is
              implementation-defined, and the scale is S1 + S2.

            d) The precision and scale of the result of division is
              implementation-defined.

         2) If the declared type of either operand of a dyadic arithmetic
            operator is approximate numeric, then the declared type of the
            result is approximate numeric. The precision of the result is
            implementation-defined.

Postgres' integer types map onto the standard as exact numerics with
scale 0.  (The precision aspect is a bit squishy, since their maximum
values aren't powers of 10, but let's disregard that.)  Postgres'
integer division operator meets the spec with the stipulation that
the "implementation-defined" scale of the result is 0.  Other SQL
implementations can and do define that differently --- if they even
have an "integer" data type, which some do not.

Anyway, the bottom line here is that we're balancing surprise factor
for novices against twenty-plus years of backwards compatibility,
and the latter is going to win.

            regards, tom lane


pgsql-general by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Database corruption in cascaded replica, "pg_xact/003A" doesn'texist, reading as zeroes"
Next
From: Achilleas Mantzios
Date:
Subject: Re: Database corruption in cascaded replica, "pg_xact/003A" doesn'texist, reading as zeroes"