Roman Artiukhin

> Your addition of the second part means that the whole thing can no longer be translated to SQL @oskarb I don't think it's true. We do support such kind...

> However, I do not know how to start with writing a test case due to needing at least two databases setup for the multitenancy scenario to make sense. Yeah...

> Isolated Work does not consider Tenancy when opening connection This one is fixed in 5.3.9 with #2835

As a workaround group by can be replaced with subquery: ```C# var result = db.Orders.Count(o => o == db.Orders.First(os => os.ShippingDate == o.ShippingDate)); ``` > The Distinct().Count() workaround fails with...

Similarly to #3000 will cause intermittent (quite often) failure builds like https://github.com/nhibernate/nhibernate-core/pull/3000#issuecomment-1016601861

I don't understand importance of Equal/NotEqual operators. Shouldn't this check at least include all others comparison operators too (, ...)

What assistance do you need? Just prepare pull request with the fix and a test case. Fix should be applied at least for all [comparison operations](https://docs.microsoft.com/en-us/dotnet/api/system.linq.expressions.binaryexpression?view=net-6.0#comparison-operations) Maybe others binary operations...

It seems we have tests to cover `DateTimeOffset`. See `DateTimeOffsetQueryFixture`. Why tests work without this changes? Can you add a failing test case there.

Ah... It is specific to column type `timestamptz` (which is not what is created by NHIbernate by default)

Original fix contains only https://github.com/nhibernate/nhibernate-core/pull/2821/commits/6f948f6792019dcdddc0c08346d87f69df735d1c. And I see no harm in this change. I agree we shouldn't add `timestampz` registrations for `DateTimeOffset` for PostreSQL if it's not supported properly. But...