>> 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
No comments:
Post a Comment