Request for backporting of ProvidePasswordCallback from 4.1.0 to 4.0.11

Before submitting

This repo is for Npgsql ADO.NET issues only. Entity Framework issues belong in Npgsql.EntityFrameworkCore.PostgreSQL for EF Core, or EntityFramework6.Npgsql for EF 6.x.

Steps to reproduce

Ideally include a complete code listing that we can run to reproduce the issue. Alternatively, you can provide a project/solution that we can run.

The issue

We are currently using .netcore 2.2 and it will take us some time to move to 3.1. However, we would really like to use the ProviderPasswordCallback feature to integrate with IAM role authentication in AWS.

Specifically this commit, https://github.com/npgsql/npgsql/commit/e600e7e49270784e6507f905c72a6a3bfd9e973e

The unfortunately part is that this is only available for Npgsql >= 4.1.0, and EFCore.pg >= 3.0.0 as we are also using EFCore.pg to setup our connections. This meant, to use this feature, we needed to upgrade to 3.0.0…

We tried to upgrade our Npgsql to 4.1.0 and somehow attach the ProvidePasswordCallback delegate manually, but we can’t seem to find a way to attach it while still using the EFCore module to setup the connection…

Further technical details

Npgsql version: 4.0.10 PostgreSQL version: 10.7 Operating system: linux

Other details about my project setup:

[ajcvickers]

@roji The problem is the use of AddDbContextPool. Since the same context instance is re-used it doesn’t get a newly created connection instance for each scope. Using AddDbContext should work.

[roji]

@isen-ng unless I’m mistaken, at the end of the day, your application is responsible for what ends up in the Where clause of the LINQ query sent to EF Core - neither OData nor Automapper should be determining that. I fully understand that the upgrade path from EF Core 2.x to 3.x is painful - the EF Core team is very aware of this, and the decision to remove client evaluation wasn’t taken lightly. But at some point you’re probably going to have to bite the bullet and go through the process. Note again that what you’re seeing are actually cases which were (most probably) client-evaluated in 2.2, so once again pulling your entire database table to the client.