Re: Fall back to alternative tsearch dictionary directory

Martin Pitt <martin@piware.de> writes:
> So far I wrote the postgresql-common infrastructure to mangle these
> dictionary/affix files to become palatable for PostgreSQL (recoding to
> UTF-8, renaming to lowercase, changing file suffix) and install them
> into /var/cache/postgresql/dicts/ whenever a {hun,my}spell-* package
> is installed or updated.

> The remaining bit is teaching postgresql to actually look into
> /var/cache/postgresql/dicts/ if it does not find a matching
> dictionary/affix file in ${sharepath}/tsearch_data/.

I can't see any reason whatever to not put them into
${sharepath}/tsearch_data/.  It's not like you're expecting to be
able to share them with other applications.

> The reasons why I'm not using ${sharepath}/tsearch_data/ in the first
> place are that
>  - it's autogenerated data, as opposed to files statically shipped in
>    a package
>  - I do not want to conflict to/overwrite files which the admin
>    manually put there.

Seems like it'd be quite sufficient to choose a specialized naming
policy within tsearch_data, say es_ES.aff -> system_es_es.aff.  I don't
think moving stuff into a different subdirectory makes conflicts a
non-problem; it just means that half the world will be unhappy with the
search order you chose.

            regards, tom lane