Re: tsearch2 in PostgreSQL 8.3?

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > The other point is that we should have a good idea of the API because
> > if it gets into 8.3 it will be harder to change.
>
> Yeah, once it's in core we have a pretty strong backwards-compatibility
> restriction to deal with. Someone upthread claimed "we can always
> simplify it later" but that's exactly backward --- we can add features
> later, but we can't subtract.
>
> Maybe we should be looking to implement just the minimum set of features
> for 8.3 and leave some of the more controversial stuff for 8.4. I hate
> to admit it, but if we take that point of view then triggers are in
> and functional-index support is out. We have to support the trigger
> approach because it's what is in tsearch2 now, and the existing users
> will expect to continue to have that option.

Triggers and expression indexes were both in the documentation Oleg
supplied, so I am sure both are being used. I bet some users don't even
know they are using expression indexes because creating a GIN index on a
column automatically casts to tsvector. (But GIST does not.) I had to
ask Oleg to find out this out.

> However, allowing the standard triggers to pay attention to a
> configuration GUC variable is simply broken; that bit has to go away.

The only trigger example supplied by Oleg and Teodor is
tsvector_update_trigger(), and that doesn't take a configuration name,
meaning it uses the default GUC configuration.

Uh, how are we going to prevent the auto-casting to tsvector from using
the default GUC config, e.g. CREATE INDEX i ON x USING GIN(col)?

This is where I started to see the need for education and error-prone
nature of the default GUC just wasn't worth having it, though I know
others disagree.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +