Support for row value comparisons

[roji]

This implements dotnet/efcore#26822 for PostgreSQL only; things are easier here because there's already full support for arrays. I don't think this blocks us if we introduce something in relational, we can always obsolete the specific methods here.

Note: the methods have the long names (e.g. RowValueGreaterThan) since PG also supports array comparison in SQL.

/cc @smitpatel @ajcvickers @mrahhal

Closes #2349

[smitpatel]

does this mean parameters are not allowed?

[roji]

Unfortunately it does, at the moment... Apparently a LINQ NewArrayExpression gets parameterized the moment it contains a parameter inside it (if we somehow got the NewArrayExpression with ParameterExpression inside it, that would work).

As for handling a ParameterExpression representing the entire row value... PG does have "composite types" (like UDT, which represents a row in a table). At the ADO level Npgsql supports mapping these to CLR types and reading/writing them, but there's no composite support at the EF provider level (#22). If it's valuable/requested I can always add that later.

Note that composite parameters would also be PG-specific: while SQLite and MySQL support row values "literals" (as supported via this PR), I don't think they have a true 1st-class type like that, so a parameterized row value is probably impossible.

Makes sense?

[roji]

It's true this restriction does limit the usefulness of this feature, since typically you'd want to parameterize the constants on the right-hand side...

[roji]

So yeah... PostgreSQL doesn't currently allow parameterizing "anonymous" row types (or records), as in npgsql/npgsql#4437 (comment). Named row types (AKA composites) can be parameterized, but that means a type must exist prior to the query, which is inappropriate here (similar to how we can't use SQL Server TVPs in various scenarios).

I can add [NotParameterizable] to the array parameters of these new functions. This stops us from trying to parameterize the entire array, but also prevents parameterization of the elements inside the array, making them into constants instead. So:

var foo = "foo";
_ = ctx.Blogs.Where(b => EF.Functions.RowValueGreaterThan(new[] { b.Name1, b.Name2 }, new[] { "A", foo })).ToList();

... yields:

SELECT b."Id", b."Name1", b."Name2"
FROM "Blogs" AS b
WHERE (b."Name1", b."Name2") > ('A', 'foo')

(where 'foo' should be a parameter instead of a constant).

[roji]

Just excluding all NewArrayExpression in EvaluatableExpressionFilter produces the right results (('A', @__foo_1)), but seems like too much... In theory if we had something like [NotParameterizable] but with more options, e.g. to prevent evaluability on a specific parameter...

OK enough, going to bed... 😴

[smitpatel]

Sounds fine to me, just wanted to make sure you have considered parameters also. Can always add it later if there is user feedback and an easy way.

[roji]

Yeah, looking at this again with fresh eyes, I guess excluding NewArrayExpression via EvaluatableExpressionFilter isn't too bad (I'm assuming evaluatable NewArrayExpressions should be rare?). Otherwise, if parameters aren't supported, this feature isn't very useful...

If you think otherwise or have some other bright idea, let me know.

[roji]

Ended up going with NewExpression of ValueTuple instead of NewArrayExpression, allowing us to disallow specifically that in EvaluatableExpressionFilter.

See #2349 (comment)

[roji]

/cc @smitpatel note these translation failure tests which now pass via row values, the resulting SQL is even a bit tighter:

WHERE (c."City", c."Country") = ('Sao Paulo', 'Brazil')

... rather than the expanded:

WHERE c."City" = 'Sao Paulo' AND c."Country" = 'Brazil'`

If we decide to bring this to relational, then specifically for SQL Server which doesn't support this, we could have a post-processing step which expands RowValueExpression to the equivalent verbose form (as above).