On Fri, Dec 19, 2014 at 10:56 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers