Re: [HACKERS] Do we need multiple forms of the SQL2003 statistics aggregates?

[Tom Lane]

I wrote:
> There is room to argue that the numeric-arithmetic version would be
> worth having on the grounds of greater precision or range, but it's a
> big chunk of code and the public demand for the functionality has not
> exactly been overwhelming.

> Comments?

Since no one's even bothered to respond, I take it there's insufficient
interest in the numeric versions of these aggregates.  I've committed
just the float8 versions.

I added some very trivial regression tests, which we'll have to keep an
eye on to see if they have any portability problems.  We may need to
back off the number of displayed fraction digits to get them to pass
everywhere.

If anyone wants to do better tests, feel free...

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] Do we need multiple forms of the SQL2003 statistics aggregates?

[Tom Lane]

Sergey's recent patch for the SQL2003 binary aggregates implements each
of them three times: in float4, float8, and numeric arithmetic.  This
seems like vast overkill.  The float4 versions certainly ought to go,
as they won't perform noticeably better than float8 and will likely be
subject to terrible roundoff-error problems.  I'm also dubious about the
numeric versions.  The spec says

b) Let DTDVE be the declared type of DVE and let DTIVE be the
declared type of IVE.

c) Case: 

i) The declared type of REGR_COUNT is an implementation-defined
exact numeric type with scale of 0 (zero).

ii) Otherwise, the declared type of the result is an
implementation-defined approximate numeric type. If DTDVE is an
approximate numeric type, then the precision of the result is
not less than the precision of DTDVE. If DTIVE is an approximate
numeric type, then the precision of the result is not less than
the precision of DTIVE.

so as far as I can see we are *only* required to provide a float8
implementation.

There is room to argue that the numeric-arithmetic version would be
worth having on the grounds of greater precision or range, but it's a
big chunk of code and the public demand for the functionality has not
exactly been overwhelming.

Comments?

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster