On Wed, Oct 11, 2017 at 10:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I don't intend to spend much time arguing about this, because you can find previous discussions in the PG archives if you're so inclined. But I do remember one simple counterexample: if you fat-finger the command syntax, say
ALTER YSER joe PASSWORD 'notsosecret'
would you still expect the logging code to figure out that it should suppress the password?
This is actually more or less what happened when I noticed it this morning. I happened to be tailing the server log when a user fat-fingered the command twice and I realized I was looking at his password as typed. I see the challenge you're presenting, but that doesn't make it acceptable to me (but obviously still not easy to fix). Yes, I now know to use \password now when I reset user passwords in psql, but I'll have see how these other developer tools are doing it. This user was using IntelliJ but I'm assuming the ALTER command was just typed into the SQL editor since it had to be corrected twice.
If you're going to log statements that fail to parse, then yes it will make it harder to close these loopholes. That's also new to me, coming from a different RDBMS world. It logs neither bad (failed to parse) SQL nor user passwords. Of course they also charge you tens of thousands of dollars per core for partitioning, so it isn't all beer and skittles.
Long-term I'm hoping to get our PG databases talking to our LDAP, there's a few internal issues and priorities that have that on the back burner for now.