>
> Well sure, but best effort is better than no effort at all. Preventing CREATE/ALTER will catch 99% of items, and as I
advocated,there really is no reason for them to be in pg_stat_statements in the first place.
>
>>
>> The clients that set passwords could simply turn off track_utility on a user/transaction level while they are
performingthe action with
>> sensitive data.
>
>
> Good point, but that relies on the client to do the right thing, and requires two extra steps.
Yes, I think relying on the client to do the right thing is a correct strategy.
> We already have things like \password in psql. The most obvious
>helper feature we could add for this on the server side is to allow
> the password to be an out-of-line parameter:
> alter role joe set password $1;
Giving the client to parametrize DDL commands seems like a good
idea overall, and it gives the client a more robust way to deal with
sensitive passwords. Of course, even if something like this becomes possible,
the responsibility is still on the client to ensure that they are not
logging the parameter values. So, the client doing the right thing
is still required.
--
Sami
Amazon Web Services (AWS)
