On Wed, Aug 5, 2015 at 10:22:48AM -0700, Josh Berkus wrote: > On 08/05/2015 10:00 AM, Alvaro Herrera wrote: > > Anyway, the patch as proposed puts the new functions in core as builtins > > (which is what Bruce seems to be objecting to). Maybe instead of > > proposing moving existing extensions in core, it would be better to have > > this patch put those two new functions alone as a single new extension > > in src/extension, and not move anything else. I don't necessarily > > resist adding these functions as builtins, but if we do that then > > there's no going back to having them as an extension instead, which is > > presumably more in line with what we want in the long run. > > For my part, I am unclear on why we are putting *any* diagnostic tools > in /contrib today. Either the diagnostic tools are good quality and > necessary for a bunch of users, in which case we ship them in core, or > they are obscure and/or untested, in which case they go in an external > project and/or on PGXN. > > Yes, for tools with overhead we might want to require enabling them in > pg.conf. But that's very different from requiring the user to install a > separate package.
I don't care what we do, but I do think we should be consistent. Frankly I am unclear why I am even having to make this point, as cases where we have chosen expediency over consistency have served us badly in the past. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
