Assuming that I'm right, you need to revert OP_AND/OP_OR/OP_NOT to what
they were before, which means you need to give up on the assumption that
the numerical values of the OP_xxx constants correspond directly to their
syntactic priority. But that assumption was never going to survive the
next ts
Teodor Sigaev writes:
>> Hasn't this patch broken on-disk compatibility of type tsquery by
>> renumbering the values of QueryOperator.operator? I'm looking at
>> the patch delta in ts_type.h.
> Distance field is placed exactly in hole between two uint8_t fields and
> uint32_t
> field, as I kno
Phrase full text search.
Hasn't this patch broken on-disk compatibility of type tsquery by
renumbering the values of QueryOperator.operator? I'm looking at
the patch delta in ts_type.h.
Distance field is placed exactly in hole between two uint8_t fields and uint32_t
field, as I known any k
I wrote:
> ... I'm looking at the patch delta in ts_type.h.
BTW, while I'm looking at that: comparePos() was a perfectly OK
name for a static function within tsvector.c, but it seems like a
pretty horrid name for a globally exposed linker symbol. Please
rename it to something less generic.
Teodor Sigaev writes:
> Phrase full text search.
Hasn't this patch broken on-disk compatibility of type tsquery by
renumbering the values of QueryOperator.operator? I'm looking at
the patch delta in ts_type.h.
regards, tom lane
--
Sent via pgsql-committers mailing lis
Phrase full text search.
Patch introduces new text search operator (<-> or ) into tsquery.
On-disk and binary in/out format of tsquery are backward compatible.
It has two side effect:
- change order for tsquery, so, users, who has a btree index over tsquery,
should reindex it
- less number of pa
