you can write
    your own.
   </para>

<synopsis>
tsvector_update_trigger(<replaceable class="parameter">tsvector_column_name</replaceable>,&zwsp; <replaceable class="parameter">config_name</replaceable>, <replaceable class="parameter">text_column_name</replaceable> <optional>, ... </optional>)
tsvector_update_trigger_column(<replaceable class="parameter">tsvector_column_name</replaceable>,&zwsp; <replaceable class="parameter">config_column_name</replaceable>, <replaceable class="parameter">text_column_name</replaceable> <optional>, ... </optional>)
</synopsis>

   <para>
    These trigger functions automatically compute a <type>tsvector</type>
    column from one or more textual columns, under the control of
    parameters specified in the <command>CREATE TRIGGER</command> command.
    An example of their use is:

<screen>
CREATE TABLE messages (
    title       text,
    body        text,
    tsv         tsvector
);

CREATE TRIGGER tsvectorupdate BEFORE INSERT OR UPDATE
ON messages FOR EACH ROW EXECUTE FUNCTION
tsvector_update_trigger(tsv, 'pg_catalog.english', title, body);

INSERT INTO messages VALUES('title here', 'the body text is here');

SELECT * FROM messages;
   title    |         body          |            tsv
------------+-----------------------+----------------------------
 title here | the body text is here | 'bodi':4 'text':5 'titl':1

SELECT title, body FROM messages WHERE tsv @@ to_tsquery('title &amp; body');
   title    |         body
------------+-----------------------
 title here | the body text is here
</screen>

    Having created this trigger, any change in <structfield>title</structfield> or
    <structfield>body</structfield> will automatically be reflected into
    <structfield>tsv</structfield>, without the application having to worry about it.
   </para>

   <para>
    The first trigger argument must be the name of the <type>tsvector</type>
    column to be updated.  The second argument specifies the text search
    configuration to be used to perform the conversion.  For
    <function>tsvector_update_trigger</function>, the configuration name is simply
    given as the second trigger argument.  It must be schema-qualified as
    shown above, so that the trigger behavior will not change with changes
    in <varname>search_path</varname>.  For
    <function>tsvector_update_trigger_column</function>, the second trigger argument
    is the name of another table column, which must be of type
    <type>regconfig</type>.  This allows a per-row selection of configuration
    to be made.  The remaining argument(s) are the names of textual columns
    (of type <type>text</type>, <type>varchar</type>, or <type>char</type>).  These
    will be included in the document in the order given.  NULL values will
    be skipped (but the other columns will still be indexed).
   </para>

   <para>
    A limitation of these built-in triggers is that they treat all the
    input columns alike.  To process columns differently &mdash; for
    example, to weight title differently from body &mdash; it is necessary
    to write a custom trigger.  Here is an example using
    <application>PL/pgSQL</application> as the trigger language:

<programlisting>
CREATE FUNCTION messages_trigger() RETURNS trigger AS $$
begin
  new.tsv :=
     setweight(to_tsvector('pg_catalog.english', coalesce(new.title,'')), 'A') ||
     setweight(to_tsvector('pg_catalog.english', coalesce(new.body,'')), 'D');
  return new;
end
$$ LANGUAGE plpgsql;

CREATE TRIGGER tsvectorupdate BEFORE INSERT OR UPDATE
    ON messages FOR EACH ROW EXECUTE FUNCTION messages_trigger();
</programlisting>
   </para>

   <para>
    Keep in mind that it is important to specify the configuration name
    explicitly when creating <type>tsvector</type> values inside triggers,
    so that the column's contents will not be affected by changes to
    <varname>default_text_search_config</varname>.  Failure to do this is likely to
    lead to problems such as search results changing