[Feature Request / Question] Ability to configure Case Insensitive Operator translation (LOWER vs UPPER)

[AlexMKotcz]

Description

Is there a way to specify or override how QueryKit translates case-insensitive operators (e.g., @=*)? Specifically, I would like to configure the provider to use UPPER(value) instead of the default LOWER(value) during the expression building process.

Context & Environment

• .NET Version: 10
• Database Provider: Npgsql (PostgreSQL)

Use Case

In my domain model, I normalize certain fields like Email to uppercase at the application level using an EF Core Value Converter. This ensures data consistency and allows me to take advantage of uppercase B-tree indexes in PostgreSQL:

builder.Property(p => p.Email)
    .HasConversion(
        v => v.ToUpperInvariant(),
        v => v);

When I perform a case-insensitive search using the QueryKit operator @=*, the resulting SQL is translated by EF Core as:

SELECT * FROM "Users" AS u
WHERE lower(u."Email") LIKE '%ALEX%'

The Problem

1. Functional Mismatch: Because the data is stored as ALEX@EXAMPLE.COM, the lower() function transforms it to alex@example.com. If the search term is provided in uppercase, the query returns no results.
2. Index Usage: Using LOWER() prevents PostgreSQL from using a standard index defined on the uppercase values. If QueryKit could be configured to produce an expression that EF translates to UPPER(), the SQL would be:

WHERE upper(u."Email") LIKE '%ALEX%'

This would correctly match my stored data and allow the database engine to utilize existing indexes effectively.

Questions

1. Does QueryKit currently provide a configuration setting (perhaps in QueryKitConfiguration) to choose between ToLower and ToUpper for case-insensitive operations?
2. If not, would you be open to a PR for this feature?
3. Could you point me toward the specific logic in the codebase where the case-insensitive expression is built so I can look into implementing a toggle?

[pdevito3]

It doesn't currently support this but shouldn't be a big lift to add a new config option and use that in the expression builder. I believe it happens in the comparison operator file, but could be off here.

If you want to take a stab at a PR go for it. Just make sure you add some tests 👍