Prev: enable_joinremoval
Next: [HACKERS] Parallel pg_dump for 9.1
From: Tom Lane on 29 Mar 2010 10:43
=?ISO-8859-2?Q?=A3ukasz_Dejneka?= <l.dejneka(a)gmail.com> writes:
> What I want to do is to use HStore data type (namely the HStore keys) in
> TSearch. I don't want use TSVector and the original ts_match_vq function,
> because I want to be able to control exact values that are passed to the
> search and not use their lexemes.

If that's what you're after, why don't you set up a text search
configuration in which the parser/dictionary are trivial and do no
transformations of the strings (beyond perhaps splitting at whitespace)?
Seems a lot easier than constructing your own datatype and all the
required support functions.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: =?ISO-8859-2?Q?=A3ukasz_Dejneka?= on 29 Mar 2010 13:05
2010/3/29 Tom Lane <tgl(a)sss.pgh.pa.us>

> =?ISO-8859-2?Q?=A3ukasz_Dejneka?= <l.dejneka(a)gmail.com> writes:
> > What I want to do is to use HStore data type (namely the HStore keys) in
> > TSearch. I don't want use TSVector and the original ts_match_vq function,
> > because I want to be able to control exact values that are passed to the
> > search and not use their lexemes.
>
> If that's what you're after, why don't you set up a text search
> configuration in which the parser/dictionary are trivial and do no
> transformations of the strings (beyond perhaps splitting at whitespace)?
> Seems a lot easier than constructing your own datatype and all the
> required support functions.
>
> regards, tom lane
>

Hi,

Thanks for the idea, but unfortunately it's not an option for me... This
needs to be expendable in the near future, so need to be a coded as a
separate function :/
 | 
Pages: 1
Prev: enable_joinremoval
Next: [HACKERS] Parallel pg_dump for 9.1