From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paesold <mpaesold(at)gmx(dot)at>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How does the tsearch configuration get selected? |
Date: | 2007-06-15 14:51:34 |
Message-ID: | 3710.1181919094@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
>> My guess right now is that we use a GUC that will default if a
>> pg_catalog configuration name matches the lc_ctype locale name, and we
>> have to throw an error if an accessed index creation GUC doesn't match
>> the current GUC.
> Where will index store index creation GUC?
It's not really the index's problem; IIUC the behavior of the gist and
gin index opclasses is not locale-specific. It's the to_tsvector calls
that built the tsvector heap column that have a locale specified or
implicit. We need some way of annotating the heap column about this.
In the case of a functional index you can expose the locale:
create index ... (to_tsvector('english'::regconfig, mytextcol))
but there's still the problem that the planner cannot match that to
a query specified as just WHERE to_tsvector(mytextcol) @@ query.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-06-15 14:54:54 | Re: How does the tsearch configuration get selected? |
Previous Message | Teodor Sigaev | 2007-06-15 14:50:04 | Re: How does the tsearch configuration get selected? |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-06-15 14:54:54 | Re: How does the tsearch configuration get selected? |
Previous Message | Teodor Sigaev | 2007-06-15 14:50:04 | Re: How does the tsearch configuration get selected? |