Showoff + guidance needed

PostgreSQL supports array types, which are simple columns that contain an array of an arbitrary element type. Even multidimensional arrays are supported. I added support a while back for mapping CLR arrays to PostgreSQL arrays, and this works great - you can have an int[] property on your entity and have it mapped to a PostgreSQL array column in the database.

The next logical step is to also translate array operations - PostgreSQL also provides operators for indexing and searching arrays, and these operations can even be optimized by indices. So, a LINQ operation such ctx.SomeEntities.Where(e => e.SomeArray[0] == 3) could be translated into SQL WHERE "e"."SomeArray"[1] = 3.

I did manage to get several such operations mapped, including indexing, comparing arrays for equality and array length - you can take a look at this test suite to see what’s currently supported (that’s the showoff part).

However, since array operations aren’t simple methods which can be translated as usual, I had to create my own NpgsqlSqlTranslatingExpressionVisitor to identify these array operations (ExpressionType.ArrayIndex, Expression.ArrayLength) and pass them through for treatment by my NpgsqlQuerySqlGenerator. Since this kind of change goes a bit deeper than usual I thought I’d request a review from the team, here’s the branch in question.

I’m particularly unsure about the way I’m checking that the member expressions are QuerySourceReferenceExpression, as a way to only translate array operations which occur on a member of an EF Core DbSet object - I want to avoid performing translation on, say, some client-side value (see the Where_indexer_closure test for an example).

[smitpatel]

@ajcvickers - Verified that all code needed to override is public and not in internal namespace.

[roji]

Have merged array operation translation support into Npgsql 2.0.0, thanks for all the guidance @smitpatel!