Re: pgsql: Phrase full text search.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Phrase full text search.
Date: 2016-04-08 13:48:49
Message-ID: 11272.1460123329@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Teodor Sigaev <teodor(at)sigaev(dot)ru> 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 known any known platform which we support uses 4-byte aligment for
> int32 type. Am I wrong?

No, I'm worried about the fact that you changed the OP_xxx constants.
Won't that cause a pre-existing tsquery operator to be read incorrectly?

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 tsquery expansion anyway. I'd suggest a static const array mapping
the OP values into their syntactic priorities.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-04-08 14:40:44 Re: pgsql: Use quicksort, not replacement selection, for external sorting.
Previous Message Teodor Sigaev 2016-04-08 09:08:17 pgsql: Rename comparePos() to compareWordEntryPos()