Re: tsearch2 in PostgreSQL 8.3?

On Wed, 15 Aug 2007, Magnus Hagander wrote:

> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> Tom Lane wrote:
>>>> Since I don't think that a datatype solution is the way to go,
>>>> I don't feel that we are as far away from an agreement as Bruce
>>>> is worried about.
>>
>>> Well, from where I sit, there is one person saying give me the foot gun,
>>> and Heikki saying he wants a bullet-proof type system, and you and I are
>>> in the middle, so the big problem is I don't see a concensus forming,
>>> and we have been discussing this for a while.
>>
>> The people who actually use tsearch2 seem to all have the same opinion ...
>> so I think we can't go too far in the bullet-proofing direction.
>>
>> But I would like a design that is bulletproof in dump/reload scenarios,
>> and I think it's fair to question that aspect of the tsearch2 design
>> because we've seen many reports of people having trouble updating
>> databases that use tsearch2.
>
> dump/reload is *the* biggest problem I've had with tsearch2 so far. But
> it hasn't been with the actual data - it's been the functions, and only
> when migrating between versions. But solving dump/reload reliably is one
> of the main things I'm hoping for in 8.3 ;-)

The dump/reload problem should be gone once tsearch2 became a part of core.
the problem is an inability to say what is a correct configuration in case
of expressional index when restoring. In any other case there are many
use cases when tsvector could be intentionally obtained using different
configurations.

>
> As for a nother use-pointer, I use different configurations in the same
> database - but only one per table. I explicitly use the to_tsvector that
> specifies a configuration always - to avoid surprising myself.
>
> I don't use the functional index part, but for new users I can see how
> that's certainly a *lot* easier. Requiring the specification of the
> configuration explicitly when creating this index I don't see as a big
> problem at all - compared to the work needed to set up triggers. But
> it's nice not to have to do it when querying. But wouldn't that be
> solved by having to_tsvector() require the configuration, but
> to_tsquery() and plainto_tsquery() not require it?

or better to introduce novice-level interface with configuration name
required and insist on using it with expressional index (don't know
if there is a machinery to do so).

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