<replaceable>select</replaceable> result, occurrences of the first column value
(the target) are replaced by the second column value (the substitute)
within the current <replaceable>query</replaceable> value. For example:
<screen>
CREATE TABLE aliases (t tsquery PRIMARY KEY, s tsquery);
INSERT INTO aliases VALUES('a', 'c');
SELECT ts_rewrite('a & b'::tsquery, 'SELECT t,s FROM aliases');
ts_rewrite
------------
'b' & 'c'
</screen>
</para>
<para>
Note that when multiple rewrite rules are applied in this way,
the order of application can be important; so in practice you will
want the source query to <literal>ORDER BY</literal> some ordering key.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Let's consider a real-life astronomical example. We'll expand query
<literal>supernovae</literal> using table-driven rewriting rules:
<screen>
CREATE TABLE aliases (t tsquery primary key, s tsquery);
INSERT INTO aliases VALUES(to_tsquery('supernovae'), to_tsquery('supernovae|sn'));
SELECT ts_rewrite(to_tsquery('supernovae & crab'), 'SELECT * FROM aliases');
ts_rewrite
---------------------------------
'crab' & ( 'supernova' | 'sn' )
</screen>
We can change the rewriting rules just by updating the table:
<screen>
UPDATE aliases
SET s = to_tsquery('supernovae|sn & !nebulae')
WHERE t = to_tsquery('supernovae');
SELECT ts_rewrite(to_tsquery('supernovae & crab'), 'SELECT * FROM aliases');
ts_rewrite
---------------------------------------------
'crab' & ( 'supernova' | 'sn' & !'nebula' )
</screen>
</para>
<para>
Rewriting can be slow when there are many rewriting rules, since it
checks every rule for a possible match. To filter out obvious non-candidate
rules we can use the containment operators for the <type>tsquery</type>
type. In the example below, we select only those rules which might match
the original query:
<screen>
SELECT ts_rewrite('a & b'::tsquery,
'SELECT t,s FROM aliases WHERE ''a & b''::tsquery @> t');
ts_rewrite
------------
'b' & 'c'
</screen>
</para>
</sect3>
</sect2>
<sect2 id="textsearch-update-triggers">
<title>Triggers for Automatic Updates</title>
<indexterm>
<primary>trigger</primary>
<secondary>for updating a derived tsvector column</secondary>
</indexterm>
<note>
<para>
The method described in this section has been obsoleted by the use of
stored generated columns, as described in <xref
linkend="textsearch-tables-index"/>.
</para>
</note>
<para>
When using a separate column to store the <type>tsvector</type> representation
of your documents, it is necessary to create a trigger to update the
<type>tsvector</type> column when the document content columns change.
Two built-in trigger functions are available for this, or 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