From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Updated tsearch documentation |
Date: | 2007-07-17 05:20:21 |
Message-ID: | 200707170520.l6H5KL213709@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
I think the tsearch documentation is nearing completion:
http://momjian.us/expire/fulltext/HTML/textsearch.html
but I am not happy with how tsearch is enabled in a user table:
http://momjian.us/expire/fulltext/HTML/textsearch-app-tutorial.html
Aside from the fact that it needs more examples, it only illustrates an
example where someone creates a table, populates it, then adds a
tsvector column, populates that, then creates an index.
That seems quite inflexible. Is there a way to avoid having a separate
tsvector column? What happens if the table is dynamic? How is that
column updated based on table changes? Triggers? Where are the
examples? Can you create an index like this:
CREATE INDEX textsearch_id ON pgweb USING gin(to_tsvector(column));
That avoids having to have a separate column because you can just say:
WHERE to_query('XXX') @@ to_tsvector(column)
How do we make sure that the to_query is using the same text search
configuration as the 'column' or index? Perhaps we should suggest:
CREATE INDEX textsearch_idx ON pgweb USING gin(to_tsvector('english',column));
so that at least the configuration is documented in the index.
--
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. +
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2007-07-17 08:14:24 | Re: Updated tsearch documentation |
Previous Message | Josh Berkus | 2007-07-17 00:06:37 | Re: Problem with recent PostgreSQL relatedpressrelease |
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2007-07-17 05:23:51 | Re: plpgsql FOR loop doesn't guard against strange step values |
Previous Message | Tom Lane | 2007-07-17 05:11:29 | Re: Rethinking user-defined-typmod before it's too late |