Обсуждение: Using HStore type in TSearch
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
#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 ) )
#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);
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;
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);
tq_in = TSQueryGetDatum(tq);
//process HStore
chkvalKeys.arrb = ARRPTR(hs);
chkvalKeys.arre = chkvalKeys.arrb + hs->size
chkvalKeys.values = STRPTR(hs);
chkvalKeys.values = STRPTR(hs);
chkvalKeys.operand = GETQUERY(tq_in);
res = ljd_exec(
<------> GETQUERY(tq_in),
<------> &chkvalKeys,
<------> true,
<------> checkcondition_str
);
<------> 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.
Łukasz Dejneka <l.dejneka@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
<br /><div class="gmail_quote">2010/3/29 Tom Lane <span dir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span><br/><blockquote class="gmail_quote" style="margin: 0pt 0pt0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">Łukasz Dejneka <<a href="mailto:l.dejneka@gmail.com">l.dejneka@gmail.com</a>>writes:<br /> > What I want to do is to use HStore data type(namely the HStore keys) in<br /> > TSearch. I don't want use TSVector and the original ts_match_vq function,<br />> because I want to be able to control exact values that are passed to the<br /> > search and not use their lexemes.<br/><br /></div>If that's what you're after, why don't you set up a text search<br /> configuration in which theparser/dictionary are trivial and do no<br /> transformations of the strings (beyond perhaps splitting at whitespace)?<br/> Seems a lot easier than constructing your own datatype and all the<br /> required support functions.<br/><br /> regards, tom lane<br /></blockquote></div><br />Hi,<br /><br />Thanks for theidea, but unfortunately it's not an option for me... This needs to be expendable in the near future, so need to be a codedas a separate function :/<br />