Skip to content

Upgrading Npgsql 2 to 3

Breaking2.2.7 → 3.2.7Breaking5New10Changed9Fixed23Other6

Full comparisonBack to Npgsql
BreakingUpgrade verdict

5 breaking changes.

In plain terms
  • Logging goes back to the older 3.1 approach, so code written for the 3.2 logging API must be changed.
  • The driver now talks to PostgreSQL entirely in binary instead of text, which is faster and more stable and no longer needs certain server settings to be configured.
  • Upgrading from 2.2 requires code changes, so read the migration guide and test thoroughly before deploying to production.
  • Parameter names like :1 are no longer allowed. If your code uses parameter names that begin with a number, rename them.
Must act Top 3 of 5 that need code or config changes

Npgsql publishes an official migration guide for version 3. It covers more than the release notes do.

Migration guide ↗

Requires Target frameworks .NETFramework4.5, .NETFramework4.5.1, .NETStandard1.3, .NETStandard2.0 from 3.2.3 (none stated before).

What you must change

Breaking5
Drops Microsoft.Extensions.Logging support, reverting logging to how it worked in Npgsql 3.1 and removing many new dependencies.
Microsoft.Extensions.Logging
3.2.2GitHub ReleaseSummarizedView source
Switches to 100% binary communication with PostgreSQL, removing the need for user-defined parameters such as DateStyle and extra_float_digits.
DateStyleextra_float_digitslc_monetary
3.0.0GitHub ReleaseSummarizedView source
Npgsql 3.0 is not a drop-in replacement for 2.2 and involves breaking changes; consult the migration guide.
3.0.0GitHub ReleaseSummarizedView source
Fixes an internal query parser issue; parameter names can no longer start with a digit, which may break existing code.
:1
3.0.6GitHub ReleaseSummarizedView source
NpgsqlConnection's DataSource property now returns a URL such as tcp://localhost:5432, breaking code that relied on its contents.
NpgsqlConnection.DataSource
3.0.5GitHub ReleaseSummarizedView source