On Sun, May 10, 2015 at 9:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Your unwillingness to make functions global or to stick PGDLLIMPORT
>> markings on variables that people want access to is hugely
>> handicapping extension authors. Many people have complained about
>> that on multiple occasions. Frankly, I find it obstructionist and
>> petty.
>
> Sure, we could export every last static function in the core code,
> and extension authors would rejoice ... while development on the core
> code basically stops for fear of breaking extensions. It's important
> not to export things that we don't have to, especially when doing so
> is really just a quick-n-dirty substitute for doing things properly.
Please name EVEN ONE instance in which core development has been
prevented for fear of changing a function API. Sure, we take those
things into consideration, like trying to ensure that there will be
type conflicts until people update their code, but I cannot recall a
single instance in six and a half years of working on this project
where that's been a real problem. I think this concern is entirely
hypothetical. Besides, no one has ever proposed making every static
function public. It's been proposed a handful of times for limited
classes of functions - in this case ONE - and you've fought it every
time despite clear consensus on the other side. I find that highly
regrettable and I'm very sure I'm not the only one.
I notice that you carefully didn't answer the other part of my
question: what gives you the right to revert my commits without
discussion or consensus, and do I have an equal right to change it
back?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
