npgsql: PostgreSQL returns inserted data in exception if insert fails

Postgres returns row data in the Detail section of its errors which is in turn captured in the PostgresException Data dictionary using the key Detail key. At first glance this makes sense but it is also leaking database data into exceptions which often get logged.

https://github.com/npgsql/npgsql/blob/191643e2f933eb308dea8345fa15ec42720c0666/src/Npgsql/PostgresException.cs#L61

For the relatively common case of violating a not-null constraint this is the data dictionary that is serialised into logs:

...
"Data": {
    "Severity": "ERROR",
    "SqlState": "23502",
    "Code": "23502",
    "MessageText": "null value in column \"email\" violates not-null constraint",
    "Detail": "Failing row contains (123, william, denton, null, 2019-06-19 01:55:53.6688).",
    "SchemaName": "service",
    "TableName": "person",
    "ColumnName": "email",
    "File": "execMain.c",
    "Line": "2008",
    "Routine": "ExecConstraints"
},
"ClassName": "Npgsql.PostgresException",
"Message": "23502: null value in column \"email\" violates not-null constraint",
"StackTrace": ...
...

In this case it’s just some PII (Personally identifiable information) of the user I inserted into my person table. But this could be much, much more serious; passwords, social security numbers, even credit card numbers and other secret tokens. Inserted data lives in the DB not in a logging system.

Proposal

I realise this is an issue with postgres itself and npgsql is just passing the message on, but I propose Npgsql should suppress the Detail message in exceptions, and instead provide an opt-in way of populating potentially unsafe properties if the user desires them. This could be viewed as a breaking change, but leaving the detail message there is not safe by default and many people will be unwittingly logging things they didn’t realise.