Michael Paesold <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster