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 QueryItems in 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 ???
    lenght 1
    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

Responses

• Re: building tsquery directly in memory (avoid makepol) at 2010-02-04 19:13:02 from Teodor Sigaev

pgsql-hackers by date

Next:	From: Alvaro Herrera	Date: 2010-02-04 18:27:44
	Subject: Re: Largeobject Access Controls (r2460)
Previous:	From: Josh Berkus	Date: 2010-02-04 18:22:23
	Subject: Re: testing cvs HEAD - HS/SR - cannot stat