On Wed, Aug 15, 2007 at 10:23:00AM -0400, Bruce Momjian wrote:
> 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.
Agh, I got stuck thinking the trigger case aagin - when you don't need to
create a vector at all.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
