Re: Redact user password on pg_stat_statements - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Redact user password on pg_stat_statements
Date
Msg-id 9e4975ae-6c51-4307-a273-16fe5c033b15@eisentraut.org
Whole thread Raw
In response to Re: Redact user password on pg_stat_statements  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 21.02.25 17:38, Andrew Dunstan wrote:
> I don't think this is such a terrible kluge. I think it's different from 
> the server log case, which after all requires access to the server file 
> system to exploit.

To me, the mechanism by which this patch works is completely nonobvious 
and coincidental, and it might get broken by unrelated changes.

I think a possible, more robust approach would be to put a field, say, 
security_sensitive into DefElem (or maybe a higher node, maybe even 
Query), and drive decisions from that.




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: GetRelationPath() vs critical sections
Next
From: Andrew Jackson
Date:
Subject: Re: Add Option To Check All Addresses For Matching target_session_attr