From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Proposal: syntax of operation with tsearch's configuration |
Date: | 2006-11-17 21:54:01 |
Message-ID: | 455E2F79.4090002@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-11-17 22:03:44 | Re: Shutting down a warm standby database in 8.2beta3 |
Previous Message | Tom Lane | 2006-11-17 20:53:35 | Re: Proposal: syntax of operation with tsearch's configuration |