Re: default_text_search_config and expression indexes - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: default_text_search_config and expression indexes
Date
Msg-id 20070731023732.GX7628@alvh.no-ip.org
Whole thread Raw
In response to Re: default_text_search_config and expression indexes  (Bruce Momjian <bruce@momjian.us>)
Responses Re: default_text_search_config and expression indexes  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.

-- 
Alvaro Herrera                 http://www.amazon.com/gp/registry/DXLWNGRJD34J
"Nadie esta tan esclavizado como el que se cree libre no siendolo" (Goethe)


pgsql-hackers by date:

Previous
From: Devrim GÜNDÜZ
Date:
Subject: Re: Machine available for community use
Next
From: ITAGAKI Takahiro
Date:
Subject: Re: Quick idea for reducing VACUUM contention