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 )
.... 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.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
