Re: Proposal: syntax of operation with tsearch's configuration - Mailing list pgsql-hackers

From Ron Mayer
Subject Re: Proposal: syntax of operation with tsearch's configuration
Date
Msg-id 455E2F79.4090002@cheapcomplexdevices.com
Whole thread Raw
In response to Re: Proposal: syntax of operation with tsearch's configuration  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> I don't see any comparable arguments about this full-text search stuff.  
>> In particular I don't see any arguments why a change would necessary at 
>> all, including why moving to core would be necessary in the first 
>> place.
> 
> AFAIR the only argument in favor of that is basically a marketing one:
> users perceive a feature as more real, or more supported, if it's in
> core.  I don't find this argument especially compelling myself.

On the flip side of that argument - the more non-SQL-standard pieces
are in core, the more "non-real" other pieces non-in-core appear.
People seem to have little doubts regarding the CPAN, or Ruby Gems.
I believe because to a large part that's because a lot of very
important and well supported functionality exists outside of their
core distributions.  The less that's pre-baked into core, I think
the more people will be aware of the rich set of extensions postgresql
enables.


From a marketing point of view (should I have moved this to .advocacy),
it seems to me the biggest problem is the name "contrib".  If it were
called "optional" or "advanced" or "extra" I think it'd be seen less
suspiciously by hosting companies (who seem to have the biggest problem
with contrib) and we wouldn't need as many discussions of which contribs
to move into core.
 Ron M



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Shutting down a warm standby database in 8.2beta3
Next
From: "Nikolay Samokhvalov"
Date:
Subject: Re: Proposal: syntax of operation with tsearch's configuration