Re: Fall back to alternative tsearch dictionary directory

Martin Pitt <martin(at)piware(dot)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