Bruce Momjian escribió:
> Mike Rylander wrote:
> > This is just my $0.02 as a fairly heavy user of the current tsearch2
> > code, but I sincerely hope you do not cripple the system by removing
> > the ability to store tsvectors built using arbitrary configurations in
> > a single column. Yes, it can lead to unexpected results if you do not
> > know what you are doing, but if you have gone beyond building a single
> > tsearch2 configuration then you are required to know what you are
> > doing. What's more, IMO the default configuration mechanism feels
> > very much like a CONSTRAINT, as Oleg suggests. That point is one of
> > cognizance, where if one has gone to the trouble of setting up
> > multiple configurations and has learned enough to do so correctly,
> > then one necessarily understands the importance of the setting and can
> > use it (or not, and use explicit configurations) correctly. The
> > default config lowers the bar to an acceptable level for beginners
> > that have no need of multiple configurations, and while I don't feel
> > too strongly, personally, about having a default, I think it is both
> > useful and helpful for new users -- it was for me.
>
> What has really hurt the default GUC idea is how to do restores from a
> pg_dump. How do you make sure the right default is used on a restore,
> particularly if multiple objects are being restored, and each has a
> different default GUC. I suppose your trigger handles that but that
> isn't going to help with an expression index, nor in cases where the
> default of the old database is different from the new one.
I guess what should happen is that pg_dump should include a
SET default_text_search_config = 'foo'
just before the CREATE INDEX, like we do for other variables. Of
course, in order for this to work, the index itself must know what value
was used on creation. Oleg already dismissed my suggestion of putting
it into the index itself (a metapage or something).
Maybe store it in reloptions?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.