Re: tsearch2 in PostgreSQL 8.3?

On Wed, 2007-08-15 at 08:10 +0200, Magnus Hagander wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce(at)momjian(dot)us> 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 ;-)

I can see the problem, but I'm sure there are more solutions than have
been listed so far.

If dump/restore is a problem we can:

1. force pg_dump to output a SET command for the GUC, so it is correctly
set at restore time. That seems like a straightforward addition to
pg_dump. Maybe this can be done in a generalised manner to support other
dump/restore configuration difficulties that might occur in the future.

2. put the desired value in a table and make sure the text_search_config
table is dumped ahead of other objects. When we restore we build the
index based on the config option set in the table, so it all just
works.

3... probably other options too.

Maybe we should consider that the user may be dumping and reloading
*because* they want the configuration to change. Just a thought.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com