diff options
| author | John Naylor <john.naylor@postgresql.org> | 2021-08-26 09:58:28 -0400 |
|---|---|---|
| committer | John Naylor <john.naylor@postgresql.org> | 2021-08-26 09:58:28 -0400 |
| commit | f8c8a8bccc23f6ca38f7a92c9a614e73fa1fcfb6 (patch) | |
| tree | a04dae626dd5a0aea99142bc63cb86e66130521a /src/backend/regex/regexec.c | |
| parent | 0d906b2c0b1f0d625ff63d9ace906556b1c66a68 (diff) | |
| download | postgresql-f8c8a8bccc23f6ca38f7a92c9a614e73fa1fcfb6.tar.gz postgresql-f8c8a8bccc23f6ca38f7a92c9a614e73fa1fcfb6.zip | |
Revert "Change mbbisearch to return the character range"
This reverts commit 78ab944cd4b9977732becd9d0bc83223b88af9a2.
After I had committed eb0d0d2c7 and 78ab944cd, I decided to add
a sanity check for a "can't happen" scenario just to be cautious.
It turned out that it already happened in the official Unicode source
data, namely that a character can be both wide and a combining
character. This fact renders the aforementioned commits unnecessary,
so revert both of them.
Discussion:
https://www.postgresql.org/message-id/CAFBsxsH5ejH4-1xaTLpSK8vWoK1m6fA1JBtTM6jmBsLfmDki1g%40mail.gmail.com
Diffstat (limited to 'src/backend/regex/regexec.c')
0 files changed, 0 insertions, 0 deletions