Re: NUMERIC private methods?

On Fri, Dec 19, 2014 at 10:56 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Well, there are two components to what I'm saying. One is that the
> example David started with looks like it could use some better-informed
> consideration about which datatype to use. The other is that numeric
> leaves quite a lot to be desired still, and someday we might want to fix
> that, and that might require breaking the APIs you want to expose.

As I say, I'm OK with that. That file has been nearly-static for a
really long time, so I don't expect a massive rewrite imminently. But
if it happens, and it breaks things for people relying on those
functions, tough luck for them.

>> 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.
>
> Really. I will remember that next time you bitch about us changing some
> extension-visible behavior, which AFAIR you are usually one of the first
> to complain about.

Really? I have bitched about what I see as nearly-pointless
reorganizations of header files, because I personally place very low
priority on speeding up incremental compiles, and most of those
changes have no other benefit. But I can't remember ever bitching
about function signature changes or changes to the types of global
variables, or even the disappearance of previously-exposed types or
global variables. And I daresay, given the nature of my
responsibilities at EDB, such things have at least one order of
magnitude more impact on me than they do on most extension
maintainers. If it were up to me, I'd go stick PGDLLIMPORT on every
global variable I could find; I estimate that would make things easier
for me, say, five times as often as it would make them harder. The
amount of time we've spent tracking down regressions on Windows
because some loadable module of ours depended on a variable that
wasn't PGDLLIMPORT'd is large - everything works fine on Linux, and
sometimes survives cursory testing on Windows too, but then breaks in
some obscure scenario. And there have also been cases where we've had
to work around the absence of PGDLLIMPORT markings with ugly hacks and
then that workaround code has turned out to be buggy. I would not
argue for indiscriminately making global every function we have
anywhere in the backend, but I would favor a policy of being
significantly more liberal about it than we have been heretofore.

> Anyway, if we do this, I concur with Alvaro's suggestion that the
> additional exposure be in a header file named something like
> numeric_private.h, so that there's less room for complaint when
> we change it.

Yes, I liked that proposal, too. Also, I'm not sure whether there's
room to worry that making those function extern rather than static
would defeat compiler optimizations that materially affect
performance. That might just be paranoia on my part, but I've seen
cases where it matters.

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