feat(db): Improve BuildCaseInsensitiveLike with lowercase

[tyroneyeh]

Improve BuildCaseInsensitiveLike with lowercase, users are more likely to input lowercase letters, so lowercase letters are used.

[Copilot]

Pull request overview

Adds PostgreSQL-specific handling for case-insensitive matching in shared DB query helpers, and tightens a user search condition to avoid unnecessary full-name matching when the search term is empty.

Changes:

• Update BuildCaseInsensitiveLike to use SQLite COLLATE NOCASE, PostgreSQL ILIKE, and LOWER(...) fallback for other DBs.
• Add a PostgreSQL-specific implementation for BuildCaseInsensitiveIn.
• Avoid adding the full-name OR condition when search == "" in GetIssuePostersWithSearch.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
models/repo/user_repo.go	Guards full-name OR condition behind search != "" to avoid redundant full-name matching when search is empty.
models/db/common.go	Adds PostgreSQL branches for case-insensitive LIKE/IN and adjusts SQLite LIKE behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[silverwind]

Does this fix any open issues? Maybe to a quick search.

[tyroneyeh]

Does this fix any open issues? Maybe to a quick search.

I did a quick search but couldn't find an existing issue for this.

[silverwind]

Ok, I also double checked in Claude, it did not find any exactly related issue.

[wxiaoguang]

Copilot recommends removing the use of ilike in PostgreSQL

If ILIKE is removed, why we still need this PR? Do you see noticeable performance difference between ToLowerASCII and ToUpperASCII?

[tyroneyeh]

If ILIKE is removed, why we still need this PR? Do you see noticeable performance difference between ToLowerASCII and ToUpperASCII?

It is anticipated that most of the user input will be in lowercase, which will reduce the case conversion rate.

[wxiaoguang]

If ILIKE is removed, why we still need this PR? Do you see noticeable performance difference between ToLowerASCII and ToUpperASCII?

It is anticipated that most of the user input will be in lowercase, which will reduce the case conversion rate.

Show me with a real world case, to show that it really brings "noticeable performance" improvement.

[wxiaoguang]

If ILIKE is removed, why we still need this PR? Do you see noticeable performance difference between ToLowerASCII and ToUpperASCII?

It is anticipated that most of the user input will be in lowercase, which will reduce the case conversion rate.

Show me with a real world case, to show that it really brings "noticeable performance" improvement.

You can do benchmark with this:

func BenchmarkCaseCast(b *testing.B) {
	b.Run("ToUpper", func(b *testing.B) {
		for b.Loop() {
			for _, tc := range upperTests {
				ToUpperASCII(tc.in)
			}
		}
	})
	b.Run("ToLower", func(b *testing.B) {
		for b.Loop() {
			for _, tc := range upperTests {
				ToLowerASCII(tc.in)
			}
		}
	})
}

For some long texts like https://www.lipsum.com/ :

BenchmarkCaseCast/ToUpper
BenchmarkCaseCast/ToUpper-12         	  555786	      1991 ns/op
BenchmarkCaseCast/ToLower
BenchmarkCaseCast/ToLower-12         	  601572	      1859 ns/op

[wxiaoguang]

By the way, you need to re-design the test cases, but not just flip their cases.

[tyroneyeh]