Re: NUMERIC private methods?

On Thu, Dec 18, 2014 at 11:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> What it boils down to is that numeric is great for storing given decimal
> inputs exactly, and it can do exact addition/subtraction/multiplication
> on those too, but as soon as you get into territory where the result is
> fundamentally inexact it is *not* promised to be better than float8.

I think what it boils down to is that several people here (and I'll
add my voice to the chorus) are saying, hey, numeric is really useful,
and we'd like to be able to manipulate numerics without all the palloc
and fmgr overhead, and your response appears to be to say, use float8.
That may be the right answer in some cases, but certainly not in all.

> We could probably improve on this if we were to redesign the algorithms
> around a concept of decimal floating-point, rather than decimal
> fixed-point as it is now. But I'm not sure how well that would comport
> with the SQL standard. And I'm very not sure that we could still do it
> once we'd tied one hand behind our backs by virtue of exporting a bunch
> of the internals as public API.

You make this argument every time somebody wants to drop static from a
function or stick PGDLLIMPORT on a variable, and frankly I think it's
pretty developer-hostile. I would much rather see us go ahead and do
those things and if people later complain that we broke stuff, we'll
go tell them to pound sand. That's what we said when people
complained about relistemp -> relpersistence, and the number of people
who are affected by a change in the system catalogs has got to be a
good two orders of magnitude more than the number of people who are
going to notice a change in the C API. Giving developers the ability
to write extensions that *might* get broken by future changes is a lot
better than not giving them that ability in the first place. There's
only a problem for the core project if we think we're bound not to
break the APIs in a future release, and I don't feel so bound.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company