Description:
Applying HISTIGNORE in client is excessive. One cannot up arrow the line one just entered to correct it:
update participants p join passwords pw on pw.password = p.old_password set p.encrypted_password = pw.encrypted_password;
Because there are no string literals in the above statement, there is no reason for it to not be available for me to up arrow and run again, and it is even safe to be written to a history file.
Since commands I enter in the client are not written to the history file until I exit the client, the filtering could be done then rather than when I enter the data and may still need it (since I typoed that command a dozen times before I got it right; having to retype or cut and paste it each time).
How to repeat:
in the client, enter the completely non-sensitive query:
update participants p join passwords pw on pw.password = p.old_password set p.encrypted_password = pw.encrypted_password;
Now hit up arrow. It's gone.
Enter:
select coutn(*) from users where (encrypted_password) !=60;
Hit up arrow to fix "count", you can't.
Suggested fix:
Apply the filtering when writing the history to disk, rather than when adding the command to the in memory history. Or at least put it in the history as REDACTED FOR SECURITY so that people understand it is not a bug but an active choice.
Additionally, I think the pattern (using regex since I don't know the pattern language of histignore) should be .*IDENTIFIED.*['"`].*:.*PASSWORD.*['"`].* so that it is only not recorded if it possibly has sensitive data.