bnspopi opened a new pull request, #74645:
URL: https://github.com/apache/airflow/pull/74645
`_PrefixPatternParam` derives the upper bound of its range scan by
incrementing the last character of the search term, which assumes the column
sorts in code-point order. Under PostgreSQL's libc collations (`en_US.utf8`)
non-ASCII characters sort by collation weights instead, so a value that does
start with the term can fall outside the range — and the range predicates run
before the substring equality that was meant to narrow them, so the row is
already gone. Searching `카페` therefore misses `카페매출집계`, as reported in #74551
for `dag_id_prefix_pattern`, `tag_name_prefix_pattern`, `name_prefix_pattern`,
`owner_prefix_pattern` and the others that share this matcher.
The bounds are now emitted only for an ASCII prefix, where code-point order
and collation order agree on the one comparison that matters (an ASCII prefix
can only ever bump to another ASCII character, since `'9' → ':'`, `'Z' → '['`
and `'z' → '{'` all fall back to a shorter prefix). For a non-ASCII prefix the
`substr(column, 1, n) = term` equality already in the clause list carries the
filter on its own, which is the exact prefix semantics and is
collation-independent for a deterministic collation.
The trade-off is that a non-ASCII prefix no longer gets an index range scan.
That seems clearly preferable to silently dropping matches, and it only affects
terms that are broken today. A range that stays index-friendly for those terms
needs collation-aware bounds (an ICU-aware successor, or `COLLATE "C"` bounds
plus a matching `text_pattern_ops` index) — happy to look at that separately if
you would rather have it in one go.
Tests: `test_to_orm_drops_the_bounds_for_a_non_ascii_prefix` pins the
compiled SQL for `카페`, `café` and `dag_카`, and the SQLite engine test gains two
Korean rows so the predicate is also checked on real rows. The existing ASCII
cases are unchanged, which is what keeps the index path covered.
The API description said `*_prefix_pattern` is index-friendly without
qualification, so it now notes that the range scan needs an ASCII prefix.
I could not run the test suite on this machine, so the first run will be CI
here; happy to follow up on anything it flags. Let me know if you want a
newsfragment — I left it out since I did not have the PR number when committing.
closes: #74551
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (Claude Code)
Generated-by: Claude Code following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
---
* Read the **[Pull Request
Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)**
for more information. Note: commit author/co-author name and email in commits
become permanently public when merged.
* For fundamental code changes, an Airflow Improvement Proposal
([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals))
is needed.
* For significant user-facing changes create newsfragment:
`{pr_number}.significant.rst`, in
[airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/airflow-core/newsfragments).
You can add this file in a follow-up commit after the PR is created so you
know the PR number.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
