This is a bit too little, especially given the later variant of concatenating values into SQL as it opens loopholes for SQL injection.

An operator should have a method accepting a MappingContext and likely a PersistentProperty that applies to it and an abstraction like R2DBC's BindMarkers. In return, we need a tuple of bind markers associated with their value and the SQL fragment. Maybe even a slimmer variant of BindTarget (without the binding identifier) would suit fit.

@mp911de Am I correct that the desired interface signature should look like this:

public interface DialectCriteriaCondition {

   BindTarget render(MappingContext context, PersistentProperty property);
}

If so, then I have a couple of questions here:

1. Criteria API by itself is an open loophole to SQL injection, like it is how it is designed, since we're build query literally by concatinating values into SQL. Maybe if we're going to address this problem, then we can do it in a separate issue, what do you think?
2. The Criteria API is a top level API designed for end users, do we want to expose MappingContext, PersistentProperty an other abstraction? They are public, but it does not seem to be desirable to expose them to users.
3. What is the custom operator is not performed on a single PersistentProperty?

1. I tend to disagree. Combinator and Comparator enums are closed types that do not allow for extensions. In return, Spring Data Relational controls what enum values are available to ensure we only specify safe operators. At some point, we have to translate criteria elements into a String. Specifically referring to the linked method, rendering of criteria elements inside of Criteria is limited to toString() usage. The actual mapping of CriteriaDefinition to Condition (the SQL DSL) happens in QueryMapper.
2. It depends on how close we want to bring MappingContext towards users. Ideally, we have an API that allows building comparators/query elements without leading users into Spring Data's Mapping infrastructure. Something like Postgres.arrayContains("first", "second") where the resulting value is used in Criteria so that users don't have to interact with methods exposed by the result object of Postgres.arrayContains(…). We have a similar arrangement in MongoDB with AggregationOperation. AggregationOperationContext handles some abstraction for mapping and I think we might end up doing something similar.

3. What is the custom operator is not performed on a single PersistentProperty?

This also crossed my mind. There could be variants where two functions compare against each other or the property is specified on the right side. So far, we have to consider this in some way. Let's however start from a simpler side first so that we can implement a first proof of concept before digging into the more complex things. It is typically easier to build something (starting from the side how things should be expressed in code) and then we can iterate on it towards a variant that handles an increasing number of usecases.