Re: tsearch2 in PostgreSQL 8.3?

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