On Thu, 16 Aug 2007, Josh Berkus wrote:


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.

Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to