On 08/05/2015 10:26 AM, Bruce Momjian wrote: > 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.
Saying "it's stupid to be consistent with a bad old rule", and making a new rule is not "expediency". -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
