Re: tsearch in core patch, for inclusion

Hi there,

sorry, if I will a bit verbose - just tried to answer to several postings.

On Wed, 24 Jan 2007, Tom Lane wrote:

>> Teodor Sigaev wrote:
>>> If there aren't objections then we plan commit patch tomorrow or
>>> after tomorrow.
>
> This is a fairly large patch and I would like the chance to review it
> before it goes in --- "we'll commit tomorrow" is not exactly a decent
> review window.
>

I see your argument, no problem with that. We intentionally announced
its availability several weeks ago.

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> I still haven't heard any argument for why this would be necessary or
>> desirable at all, other than that it looks better for marketing
>> reasons,
>
> One possible argument for this over the contrib version is a saner
> approach to dumping and restoring configurations. However, as against
> that:
>
> 1) what's the upgrade path for getting an existing tsearch2
> configuration into this implementation?

this is a real question and we will prepare UPGRADE notes.

>
> 2) once we put this in core we are going to be stuck with supporting its
> SQL API forever. Are we convinced that this API is the one we want?
> I don't recall even having seen any proposal or discussion. It was OK
> for tsearch2's API to change every release while it was in contrib, but
> the expectation of stability is a whole lot higher for core features.

If you're talking about SQL and psql commands, than they are new and we tried
to be consistent with existing approach to manage system objects.
Any inconsistence we'd be happy to discuss and improve.

I don't remember we changed operators and function for a long
time, so users of tsearch2 should not be confused.

After all, our intention is to meet user's wish to have FTS in PostgreSQL and
nothing more. We several times wrote in mailing list that it's too early
to move tsearch2 to the pg core, since we consider (that time) it has some
scalability problem. GiN was specially developed to solve this problem and
it did it.

It's de facto standard to have FTS in modern database and
it has no difference how you call it - plugin, extension, contrib module or
built-in.

It's infair to compare approach of commercial DB with postgres, since
they have their own marketing police - they charge separately for every
extension ! Our usual peer - MySQL has built-in FTS, for example, and
I don't see any objections to not have an additional argument for our
PR people, since our FTS is a way better.

I agree, that requirements for core features should be stronger
that for contrib module, especially, for the stability of API. So, let us
discuss it. We are open for suggestions for about 6 years :)
I
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru)
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83