Database design for separate tsearch table

From: Mikkel Hgh <m(at)ooh(dot)dk>
To: pgsql-general(at)postgresql(dot)org
Subject: Database design for separate tsearch table
Date: 2008-10-22 22:10:19
Message-ID: 20081022221019.GA16207@samson.jerusalem.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

I'm trying to make a module allowing Drupal to take advantage of
PostgreSQL's excellent Full Text Search, aka. tsearch.

Since this module will probably not become part of Drupal core right off
the bat, I need to do this without modifying Drupal's own tables, so I've
created a new one for the purpose, "tsearch_node".

I'm pondering how best to do this. Basic minimum is a column which holds
the foreign key (nid) to Drupal's node.

I'm wondering whether to merge all the searchable stuff when creating the
index or to have a separate tsvector column for each of the three
commonly indexable things about Drupal content (nodes), namely the title,
the body and taxonomy. Any insights?

Also, I figure it'd be a good idea to keep the language of the indexed
content right there in the same table, since Drupals own node table
specifies two-letter codes (en, da, pt, etc.) and as far as I can
understand the PostgreSQL documentation, tsearch expects the full
language name (english, danish, portuguese), so to use it in queries
without having to do too much magic would require me to store the full
name right there in the table, or am I mistaken?

Kind regards,

Mikkel Hgh

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2008-10-22 22:25:33 Re: join question
Previous Message Guillaume Lelarge 2008-10-22 21:56:16 Re: triggers problems whit function