| From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | 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 15:16:17 |
| Message-ID: | CAE2gYzx_kC06hQkvF6VsFgt_47+vPfevsWee5gqy95LJE59PvQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> I can't imagine how this could ever work, since a non C-collation
> string cannot be atomized into tokens like that. Considering each
> token successively during a comparison does not always produce the
> same answer as a straight comparison against the original string
> would.
I think the only fix is to remove support for those operators from the
operator class. The logic on match_special_index_operator() doesn't
seem to need any change. Patch attached. As far as I understand, we
cannot back-patch catalog changes. In this case, we can leave it
broken and apply the documentation part.
| Attachment | Content-Type | Size |
|---|---|---|
| remove-wrong-spgist-text-operators-v00.patch | application/octet-stream | 24.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vitaly V. Voronov | 2018-04-16 15:42:32 | Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre |
| Previous Message | Emre Hasegeli | 2018-04-16 14:55:59 | Re: Standby corruption after master is restarted |