I am confused by the CREATE FULLTEXT CONFIGURATION command:
http://momjian.us/expire/fulltext/SGML/ref/create-fulltext-config.sgml
First, why are we specifying the server locale here since it never
changes:
<varlistentry> <term><literal>LOCALE</literal></term> <listitem> <para> <replaceable
class="PARAMETER">localename</replaceable> is the name of the locale. It should match server's locale
(<varname>lc_ctype</varname>) to identify full-text configuration used by default. </para> </listitem>
</varlistentry>
Second, I can't figure out how to reference a non-default
configuration. The description says:
<varlistentry> <term><LITERAL>AS DEFAULT</LITERAL></term> <listitem> <para> Set <literal>default</literal>
flagfor the configuration, which used to identify if this configuration is selectable on default (see
<LITERAL>LOCALE</LITERAL>description above). It is possible to have <emphasis>maximum one</emphasis> configuration
with the same locale and in the same schema with this flag enabled. </para> </listitem> </varlistentry>
The documentation says that the first fulltext configuration found in
the search patch is the one used, so how does a secondary configuration
in the same schema actually get accessed by @@ or ::tsquery? Do you
have to use to_tsquery() with the optional configuration name?
Is this really the direction we want to go, having a default that gets
picked up from the search_path, perhaps based on some encoding/locale
match I can't figure out, or do we want to require the configuration to
be specified always, and if we do that, how do we handle the @@
operator?
I am thinking we should just have use the first fulltext configuration
from the first schema in the search path and eliminate naming the
configurations (same as schema name?). Allowing configuration names to
be specified only sometimes is confusing. Or we can use a GUC to name
the configuration we want to use specifically, rather than have a
read-only tsearch_conf_name (is it read-only?) that is controlled by the
search_path.
And why are we talking locale here instead of encoding? And since we
only have one encoding per database, how can there be more than one? Is
this _client_ encoding?
FYI, while the configuration selection needs work, the rest of the areas
seem logical.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
