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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq