Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
>
> > > 3) Remove default_text_search_config and require the
> > > configuration to be specified in each function call.
> > >
> > > If we remove default_text_search_config, it would also make ::tsvector
> > > casting useless as well.
> >
> > OK, I just found a case that I think is going to make #3 a requirement
> > (remove default_text_search_config).
> >
> > How is a CREATE INDEX ... to_tsvector(col) going to restore from a
> > pg_dump? I see no way of guaranteeing that the
> > default_text_search_config is correct on the restore, and in fact I
> > don't think we have any way of knowing the default_text_search_config
> > used for the index.
>
> Make pg_dump emit only CREATE INDEX sentences with two-param format. In
> fact I think it would make sense to convert internally the one-param
> format to two-param, before hitting the catalogs.
>
> This would also solve your problem about usability of WHERE clauses, if
> you rewrite the one-param calls to two-params before the optimizer kicks
> in.
Yes, that could be done but as far as I know we weren't planning to have
those areas of our backend be aware of configuration parameters to
text search functions, and I doubt we want to do that for 8.3, if ever.
There are many tsearch functions and doing this would spill tsearch
function checks all over the backend, reducing our modularity.
The default capability just isn't worth it, and in addition is
error-prone.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
