Re: SOLVED: tsearch2 dictionary for statute cites

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>
Cc: <pgsql-general(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: SOLVED: tsearch2 dictionary for statute cites
Date: 2009-04-08 16:04:57
Message-ID: 49DC84D9.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> wrote:
>> I probably just need to have that "Aha!" moment, slap my forehead,
and
>> move on; but I'm not quite understanding something. The answer to
>> this question could be it: Can I use a different set of
dictionaries
>> for creating the tsquery than I did for the tsvector?
>
> Sure ! For example, you want to index all words, so your
dictionaries
> doesn't have stop word lists, but forbid people to search common
words.
> Or, if you want to search 'to be or not to be' you have to use
> dictionaries without stop words.

I found a creative solution which I think meets my needs. I'm posting
both to help out anyone with similar issues who finds the thread, and
in case someone sees an obvious defect. By creating one function to
generate the "legal" tsvector (which recognizes statute cites) and
another function to generate the search values, with casts from text
to the ts objects, I can get more targeted results than the parser and
dictionary changes alone could give me.

I'm still working on the dictionaries and the query function, but the
vector function currently looks like the attached.

Thanks to Oleg and Tom for assistance; while neither suggested quite
this solution, their comments moved me along to where I found it.

-Kevin

Attachment Content-Type Size
to_legal_tsvector.sql application/octet-stream 890 bytes

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jennifer Trey 2009-04-08 16:05:26 Re: Now I am back, next thing. Final PGS tuning.
Previous Message Ian Mayo 2009-04-08 15:56:35 Re: Are there performance advantages in storing bulky field in separate table?