Magnus Hagander wrote: > > But I would like a design that is bulletproof in dump/reload scenarios, > > and I think it's fair to question that aspect of the tsearch2 design > > because we've seen many reports of people having trouble updating > > databases that use tsearch2. > > dump/reload is *the* biggest problem I've had with tsearch2 so far. But > it hasn't been with the actual data - it's been the functions, and only > when migrating between versions. But solving dump/reload reliably is one > of the main things I'm hoping for in 8.3 ;-) > > As for a nother use-pointer, I use different configurations in the same > database - but only one per table. I explicitly use the to_tsvector that > specifies a configuration always - to avoid surprising myself. > > I don't use the functional index part, but for new users I can see how > that's certainly a *lot* easier. Requiring the specification of the > configuration explicitly when creating this index I don't see as a big > problem at all - compared to the work needed to set up triggers. But > it's nice not to have to do it when querying. But wouldn't that be > solved by having to_tsvector() require the configuration, but > to_tsquery() and plainto_tsquery() not require it?
Yea, I have thought about splitting up the behavior so tsvector always needs the configuration but tsquery does not. However, for a query, you are probably still creating a tsvector so it didn't see to help much in clarity. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
