Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Since I don't think that a datatype solution is the way to go, >>> I don't feel that we are as far away from an agreement as Bruce >>> is worried about. > >> Well, from where I sit, there is one person saying give me the foot gun, >> and Heikki saying he wants a bullet-proof type system, and you and I are >> in the middle, so the big problem is I don't see a concensus forming, >> and we have been discussing this for a while. > > The people who actually use tsearch2 seem to all have the same opinion ... > so I think we can't go too far in the bullet-proofing direction. > > 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? //Magnus ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings