building tsquery directly in memory (avoid makepol) - Mailing list pgsql-hackers

From Ivan Sergio Borgonovo
Subject building tsquery directly in memory (avoid makepol)
Date
Msg-id 20100204192402.1a9e9a73@dawn.webthatworks.it
Whole thread Raw
Responses Re: building tsquery directly in memory (avoid makepol)
List pgsql-hackers
I know in advance the structure of a whole tsquery, it has already
been reduced and lexemes have been already computed.
I'd like to directly write it in memory without having to pass
through pushValue/makepol.

Anyway I'm not pretty sure about what is the layout of a tsquery in
memory and I still haven't been able to find the MACRO that could
help me [1].

Before doing it the trial and error way can somebody just make me an
example?
I'm not pretty sure about my interpretation of the comments of the
documentation.

This is how I'd write
X:AB | YY:C | ZZZ:D

TSQuery vl_len_ (total # of bytes of the whole following structure QueryItems*size + total lexeme length) size (# of
QueryItemsin the query) QueryItem   type QI_OPR   oper OP_OR   left -> distance from QueryItem X:AB QueryItem   type
QI_OPR  oper OP_OR   left -> distance from QueryItem ZZZ:D QueryItem (X)    type QI_VAL   weight 1100   valcrc ???
lenght1   distance QueryItem (YY)   type QI_VAL   weight 0010   valcrc ???   lenght 2   distance QueryItem (ZZZ)   type
QI_VAL  weight 0001   valcrc ???   lenght 3   distance     X     YY     ZZZ
 

[1] the equivalent of POSTDATALEN, WEP_GETWEIGHT, macro to compute
the size of various parts of TSQuery etc...

I couldn't see any place in the code where TSQuery is built in "one
shot" in spite of using pushValue.

Another thing I'd like to know is: what is going to be preferred
during a scan between
'java:1A,2B '::tsvector @@ to_tsquery('java:A | java:B');
vs.
'java:1A,2B '::tsvector @@ to_tsquery('java:AB')
?
they look equivalent. Are they?

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: testing cvs HEAD - HS/SR - cannot stat
Next
From: Alvaro Herrera
Date:
Subject: Re: Largeobject Access Controls (r2460)