Teodor Sigaev wrote:
As for downsides, I only really see two:
* Tracking updates of dictionaries - but it's reasonable to believe
that new connections get open more often than the dictionary gets
updated. Also, this might be easily solved by stat()-ing the
dictionary file before starting up session, and only have the server
reload it if there's a notified change.
* Possibly complicated to implement?
Keeping dictionary up to date - it's a most difficult part here.
Configuration of dictionary might be done by ALTER command - so, parent
process (and all currently running backends) should get that information
to reload dictionary.
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?
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.
Yes, of course, you can develop your dictionary (-ies) and parser. Dut
only in C, because they are critical for performance.
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?
Best regards,
Steve
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general