On Mon, Nov 14, 2011 at 8:44 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> On 11/14/2011 07:56 PM, Josh Berkus wrote:
>>
>> So I'm a bit unclear on why most of the optional data types were
>> excluded from your list of Core Extensions.
>
> I was aiming for the extensions that seemed uncontroversial for a first pass
> here. One of the tests I applied was "do people sometimes need this module
> after going into production with their application?" The very specific
> problem I was most concerned about eliminating was people discovering they
> needed an extension to troubleshoot performance or corruption issues, only
> to discover it wasn't available--because they hadn't installed the
> postgresql-contrib package. New package installation can be a giant pain to
> get onto a production system in some places, if it wasn't there during QA
> etc.
>
> All of the data type extensions fail that test. If you need one of those,
> you would have discovered that on your development server, and made sure the
> contrib package was available on production too. There very well may be
> some types that should be rolled into the core extensions list, but I didn't
> want arguments over that to block moving forward with the set I did suggest.
> We can always move more of them later, if this general approach is
> accepted. It only takes about 5 minutes per extension to move them from
> contrib to src/extension, once the new directory tree and doc section is
> there. But I didn't want to do the work of moving another 15 of them if the
> whole idea was going to get shot down
I continue to think that we should be trying to sort these by subject
matter. The term "core extensions" doesn't convey that these are
server management and debugging tools, hence Josh's confusion.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
