Using HStore type in TSearch

Lists: pgsql-hackers
From: Łukasz Dejneka <l(dot)dejneka(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Using HStore type in TSearch
Date: 2010-03-29 11:18:04
Message-ID: 4df5da451003290418h41400685g26ae6a7dc2f50944@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi,

I've asked this question in novice group and another Postgres forum, but
didn't get any help.

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.

I'm pretty green about Postgres and C, so please forgive me for any mistakes
I make here...

What I tried was to modify the ts_match_vq function and use it to pass
values from HStore directly to the recursive TS_execute function.
Unfortunately the HStore ARRPTR() and STRPTR() functions do not return the
same structures as their TSVector counterparts. HStore as I gathered returns
pointer to a string, but the TSVector (and the TS_execute) needs a ltree of
search entries. I guess I need to convert the HStore values to the ltree
structure, but I can't get it right.

This is the partially modified ts_match_vq:

#undef CALCDATASIZE
#undef ARRPTR
#undef STRPTR
#define CALCDATASIZE(x, lenstr) ( (x) * sizeof(HEntry) + HSHRDSIZE +
(lenstr) )
#define ARRPTR(x) ( (HEntry*) ( (char*)(x) + HSHRDSIZE ) )
#define STRPTR(x) ( (char*)(x) + HSHRDSIZE + ( sizeof(HEntry)
* ((HStore*)x)->size ) )

PG_FUNCTION_INFO_V1(ljd_test);
Datum ljd_test(PG_FUNCTION_ARGS);
Datum.
ljd_test(PG_FUNCTION_ARGS).
{
//get arguments
HStore <---><------>*hs = PG_GETARG_HS(0);.
TSQuery <--><------>tq = PG_GETARG_TSQUERY(1);
TSQuery <--><------>tq_in;
CHKVAL <---><------>chkvalKeys;
bool <-----><------>res;

//check for empty values.
if (!hs->size || !tq->size)
{
<------>PG_FREE_IF_COPY(hs, 0);
<------>PG_FREE_IF_COPY(tq, 1);
<------>PG_RETURN_BOOL(false);
}
//process TSQuery
tq_in = TSQueryGetDatum(tq);
//process HStore
chkvalKeys.arrb = ARRPTR(hs);
chkvalKeys.arre = chkvalKeys.arrb + hs->size
chkvalKeys.values = STRPTR(hs);
chkvalKeys.operand = GETQUERY(tq_in);
res = ljd_exec(
<------> GETQUERY(tq_in),
<------> &chkvalKeys,
<------> true,
<------> checkcondition_str
);

PG_RETURN_BOOL(res);.

}
Thank you in advance for any help and tips on how to solve this.


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Łukasz Dejneka <l(dot)dejneka(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using HStore type in TSearch
Date: 2010-03-29 14:43:14
Message-ID: 12820.1269873794@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

=?ISO-8859-2?Q?=A3ukasz_Dejneka?= <l(dot)dejneka(at)gmail(dot)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


From: Łukasz Dejneka <l(dot)dejneka(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using HStore type in TSearch
Date: 2010-03-29 17:05:44
Message-ID: 4df5da451003291005u6722397ew86c73107884adb8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

2010/3/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>

> =?ISO-8859-2?Q?=A3ukasz_Dejneka?= <l(dot)dejneka(at)gmail(dot)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 :/