Re: How does the tsearch configuration get selected?
| От | Tom Lane |
|---|---|
| Тема | Re: How does the tsearch configuration get selected? |
| Дата | |
| Msg-id | 3710.1181919094@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: How does the tsearch configuration get selected? (Teodor Sigaev <teodor@sigaev.ru>) |
| Ответы |
Re: How does the tsearch configuration get selected?
Re: How does the tsearch configuration get selected? |
| Список | pgsql-hackers |
Teodor Sigaev <teodor@sigaev.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
В списке pgsql-hackers по дате отправления: