Emit postgres log messages that have security or PII with special flags/error code/elevel

Hi,

Today, postgres doesn't distinguish the log messages that it emits to
server logs via ereport/elog mechanism, based on security information or
PII (Personally Identifiable Information) or other sensitive information
[1]. In production environments, these log messages would be captured and
stored (perhaps in a different intermediate database specially designed for
text and log analytics) for debug, analytical, reporting or
on-demand-delivery to the customers via portal/tools. In this context, the
customers will expect to treat the sensitive information differently
(perhaps encode/mask before storing) for security and compliance purposes.
Also, it's not safe to show all the log messages as-is for internal
debugging purposes as the sensitive information can be misused
intentionally or unintentionally.

Today, one can implement an emit_log_hook which can look for sensitive log
messages based on the errmsg i.e. "text" and treat them differently. But
the errmsg based approach has its own disadvantages - errmsg can get
tweaked, there can be too many sensitive type log messages, not everyone
can rightly distinguish what a sensitive log message is and what is not,
the hook implementation and maintainability is a huge problem in the long
run.

Here's an idea - what if postgres can emit log messages that have sensitive
information with special error codes or flags? The emit_log_hook
implementers will then just need to look for those special error codes or
flags to treat them differently.

Thoughts?

[1]
errmsg("role \"%s\" cannot be dropped because some objects depend on it"
errmsg("role \"%s\" already exists"
errmsg("must have admin option on role \"%s\""
errmsg("role \"%s\" is a member of role \"%s\""
errmsg("must have admin option on role \"%s\""
errmsg("pg_hba.conf rejects replication connection for host \"%s\", user
\"%s\", %s"
errmsg("duplicate key value violates unique constraint \"%s\""
log_connections and log_disconnections messages
.....
.....

Regards,
Bharath Rupireddy.