Hmm, good point; I presume "accept the fact that settings change won't
propagate to other backends until reconnect" would not be acceptable
behavior, even if documented along with the relevant configuration option?
I suppose so. That was one of the reasons to move tsearch into core and it will
be too regrettable to lost that feature again.
As for my second question, is it possible to use functions in
tsearch2? For example, writing my own stemmer in PL/pgSQL or in C as
a postgres function.
I've had something different in mind. Considering there are already
facilities to use functions, be it PL/pgSQL, PL/Python or C, why not
just use those with the condition that the function must accept
some-arguments and return some-result? Or would using this, even while
using C as the language used for the actual parser, slow things down too?
API to dictionary and parser intentionally utilizes complex (and nested)
C-structures to decrease overheads. During parse of text postgres makes two call
of parser (one call - parser returns word, second - word delimiter. Space is a
lexeme too! Although it's not a subject to index) and one call of dictionary per
word. So, if your language can work with C-structures then you can use that
language with tsearch with more or less performance pay. PL/pgSQL hasn't this
capability.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
