Fix large number search in Postgres databases

[hanneskuettner]

Scope

What's changed:

• Introduced a DB helper that wraps the intended changes for the Postgres client only and defaults for all others
• Blackbox test need to be added, but the current state of blackbox tests does not allow that, so instead I manually tested the change and verified that the issue does not exist in other DB vendors.

Potential Risks / Drawbacks

None

Review Notes / Questions

• Since this is the first time for me touching on DB helpers, is this one implemented in the correct spirit?
• I also added a unit test case to specifically single out the helper usage in the applySearch function, I am unsure if that is the right location for it or if this should be dropped?

---

Fixes #17946

[changeset-bot]

⚠️ No Changeset found

Latest commit: 160b982

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[hanneskuettner]

Since blackbox tests aren't really in a working state right now I've tested searching large numbers with every database provider.

DB	State	Notes
MySQL	✅
MariaDB	✅
MS SQL	❓	Not running on my M3 MacBook
OracleDB	❓	Wasn't able to run it
CockroachDB	✅
Postgres	✅
RedShift	❓	Don't have access to any instance

I would appreciate hints on running the oracle docker we have in the development compose file as it fails with some networking issues on my end.

[br41nslug]

Oracle and Postgres work as expected ✅
MS SQL still seems to have issues around bigInts and searching in my tests, will dive a bit deeper as you had issues getting that one running

Error: select top (@p0) [test_2].[id], [test_2].[big_int], [test_2].[int], [test_2].[string] from [test_2] where (([test_2].[id] = @p1) or ([test_2].[big_int] = @p2) or ([test_2].[int] = @p3) or LOWER([test_2].[string]) LIKE @P4) order by [test_2].[id] asc - Bigint must be safe integer or must be passed as string, saw 9223372036854775000

select top (@p0) [test_2].[id], [test_2].[big_int], [test_2].[int], [test_2].[string] from [test_2] where (([test_2].[id] = @p1) or ([test_2].[big_int] = @p2) or ([test_2].[int] = @p3) or LOWER([test_2].[string]) LIKE @P4) order by [test_2].[id] asc - The conversion of the nvarchar value '9223372036854775000' overflowed an int column.

[br41nslug]

Since orWhere is pretty generic what do you think of something like addSearchCondition

[br41nslug]

Reminder to myself or hannes to move this to a util file