Re: tsearch2 in PostgreSQL 8.3? - Mailing list pgsql-hackers

From Oleg Bartunov
Subject Re: tsearch2 in PostgreSQL 8.3?
Date
Msg-id Pine.LNX.4.64.0708162250050.18739@sn.sai.msu.ru
Whole thread Raw
In response to Re: tsearch2 in PostgreSQL 8.3?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: tsearch2 in PostgreSQL 8.3?
List pgsql-hackers
On Thu, 16 Aug 2007, Josh Berkus wrote:

> All,
>
> First off, I'll assert that backup/restore is a serious issue and while the
> folks who want Tsearch in core now are dismissing it, we'll be fielding the
> complaints later.  Any solution which involves setting a GUC at restore time
> *which could vary per table or even column* isn't acceptable.  We used to do
> the \SET thing for table ownership with backup/restore, and you *know* how
> many restore failures that caused.
>
> Basically, restore happens at two times: (1) when the server fails and you
> need to recover, and (2) when you're upgrading, already a painful process.
> Glitches which occur at these times cause panic, angry user e-mails and
> people switching away from PostgreSQL.  It's just not acceptable for us to
> put new potential booby-traps in the way of restore.
>
> Second, as attractive as the idea is, I can't see how a typemod would work.
> It's not like we have a fixed list of dictionaries; people can create their
> own.  If we wanted to clean up the syntax I suppose we could have a form of
> to_tsvector which took a two-column composite value as if it were a
> multicolumn index:
>
> CREATE INDEX resumes_fti ON resumes USING GIN ( 'default', resume_text )

Josh, all my respects to you, but text searching is not about index at all.
Text searching is about tsvector and tsquery data type

>
> .... hmmm, that wouldn't work as syntax, would it?  We can't accept a constant
> as a column in a multi-column index, can we?  Another reason why we can't do
> mods for 8.3.
>
> This means, from my perspective, that the only reasonable course for 8.3 is to
> require the 2-parameter form of to_tsvector for indexes.  I'll say that in
> the applications I've developed with TSearch2 I use the 2-parameter form of
> to_tsvector and to_tsquery exclusively, as I've found the behavior of TSearch
> to be highly unreliable if I don't specify.
>
>
    Regards,        Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83


pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: building gist index on int[] field is terrible slow. Is it bug?
Next
From: Oleg Bartunov
Date:
Subject: Re: building gist index on int[] field is terrible slow. Is it bug?