From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Emre Hasegeli <emre(at)hasegeli(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Wrong Results from SP-GiST with Collations |
Date: | 2018-04-16 18:51:06 |
Message-ID: | 19693.1523904666@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> Has the operator class really been completely broken since SP-GiST was
> first introduced? I tend to doubt that. spg_text_inner_consistent()
> has the following code, which appears to acknowledge the problem with
> non-C collations:
You're on to something, but I think the bug is in
spg_text_leaf_consistent, which thinks it can do collation-aware
comparisons like this:
r = varstr_cmp(fullValue, Min(queryLen, fullLen),
VARDATA_ANY(query), Min(queryLen, fullLen),
PG_GET_COLLATION());
That's got nothing to do with reality for non-C collations, and it seems
rather pointless anyway, Why isn't this just
r = varstr_cmp(fullValue, fullLen,
VARDATA_ANY(query), queryLen,
PG_GET_COLLATION());
and then the bit below about
if (r == 0)
{
if (queryLen > fullLen)
r = -1;
else if (queryLen < fullLen)
r = 1;
}
needs to move into the "non-collation-aware" branch.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-04-16 19:19:36 | Re: Wrong Results from SP-GiST with Collations |
Previous Message | Peter Geoghegan | 2018-04-16 18:35:05 | Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre |