Re: tsearch2 in PostgreSQL 8.3?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: tsearch2 in PostgreSQL 8.3?
Date: 2007-08-15 03:05:34
Message-ID: 200708150305.l7F35Y525876@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> * For queries, there is not anything very wrong with having a default
> configuration, but the trick is how to get the planner to match that up
> with an index that's written with the two-parameter form of to_tsvector.
> One hackish possibility is to define the single-parameter form of
> to_tsvector like this:
>
> create function to_tsvector(text) returns tsvector as $$
> select to_tsvector(get_default_text_search_config(), $1)
> $$ language sql strict stable;
>
> where get_default_text_search_config() is essentially just
> current_setting('default_text_search_config') except it is
> misleadingly marked immutable. Then, a query with
>
> WHERE to_tsvector(document_col) @@ tsquery(...)
>
> will have the SQL function inlined, and the
> get_default_text_search_config() call const-folded, and suddenly
> it looks like
>
> WHERE to_tsvector('english', document_col) @@ tsquery(...)

This is an interesting idea that would allow queries without a
configuration to match an expression index. The only trick is to train
users not to use such tricks on triggers or expression index, but only
in queries. The idea of 'stable' helps to fix that for expression
indexes, but not for trigger use, I assume.

> * I'm not enamored of Heikki's idea about a datatype-based solution,
> because I don't think that it will allow columns containing tsvectors
> derived with different configurations. It's perfectly clear that
> advanced users want to be able to do that, and it's also clear that
> as long as the config name is coming from a stored column (or can be
> reconstructed somehow from the stored data) that it's perfectly
> well-defined.
>
> Since I don't think that a datatype solution is the way to go,
> I don't feel that we are as far away from an agreement as Bruce
> is worried about.

Well, from where I sit, there is one person saying give me the foot gun,
and Heikki saying he wants a bullet-proof type system, and you and I are
in the middle, so the big problem is I don't see a concensus forming,
and we have been discussing this for a while.

--
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. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-08-15 03:13:23 Re: tsearch2 in PostgreSQL 8.3?
Previous Message Tom Lane 2007-08-15 02:59:46 Re: CVS corruption/mistagging?