Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> 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?


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

Donate to the PostgreSQL Project:
PostgreSQL Replication:

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to