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
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() |