Re: tsearch2 in PostgreSQL 8.3?

Michael Paesold <mpaesold(at)gmx(dot)at> writes:
> Teodor Sigaev wrote:
>>> 2) added operator class for text and varchar
>>> CREATE INDEX idxname ON tblname USING GIN ( textcolumn );

> So just remove the operator class or don't specify it as default
> operator class for GIN, and the thing is gone. Perhaps there is a better
> way to do this, though.

> [...digging...] The idea was born in the thread starting here (involving
> Tom Lane, Joshua Drake, and Teodor Sigaev):
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg00912.php
> with the conclusion here:
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg00936.php

Yeah, unfortunately we overlooked the implications of the conversion to
tsvector being environment-dependent. Those opclasses will have to go
away again. AFAICS the only safe way to build an index directly on a
text column is

CREATE INDEX idxname ON tblname USING gin (to_tsvector('config', textcolumn));

ie, you hardwire the configuration name directly into the index
definition. Similarly, if you're using a trigger to build a
materialized tsvector column, you need to hardwire the config
name into the trigger definition.

An alternative in both cases is to take the config name from
another field of the table row. This is what you'd need to do
for the advanced cases where you use different configs for
different entries in the same table.

We can still have a GUC default_text_search_config, but we have
to design the system around the assumption that that should only
be referenced during *queries*, not during updates. That's the
only safe way to let it be changeable.

regards, tom lane