Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> O.k. I am not trying to throw any cold water on this, but with the
>> limitations we are suggesting, does the patch gain us anything over just
>> leaving tsearch in contrib?
>
> Well, if you want to take a hard-nosed approach, no form of the patch
> would gain us anything over leaving it in contrib, at least not from a
> functionality standpoint. The argument in favor has always been about
> perception, really: if it's a "core" feature not an "add-on", then
> people will take it more seriously. And there's a rather weak
> ease-of-use argument that you don't have to install a contrib module.
> (The idea that it's targeted at people who can't or won't install a
> contrib module is another reason why I think we can skip user-defined
> parsers and dictionaries ...)
Well my argument has always been the "core" feature argument. Perhaps I
am missing some info here, but when I read what you wrote, I read that
Tsearch will now be "harder" to work with. Not easier. :(
Removal of pg_dump support kind of hurts us, as we already have problems
with pg_dump support and tsearch2. Adding work to have to re-assign
permissions to vector columns because we make changes...
I would grant that having the SQL extensions would certainly be nice.
Anyway, I am not trying to stop the progress. I would like to see
Tsearch2 in core but I also don't want to add complexity. You did say here:
And we reserve the right to whack around the API for the functions
referenced by the catalog entries.
Which kind of gets us back to upgrade problems doesn't it?
Sincerely,
Joshua D. Drake
>
> regards, tom lane
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/