On 9/25/14, 1:41 AM, David Johnston wrote:
If the error message is written correctly most people upon seeing the error will simply fix their configuration and move on - regardless of whether they were proactive in doing so having read the release notes.
The important part to realize here is that most people will never see such an error message. There is a person/process who breaks the postgresql.conf, a process that asks for a configuration restart/reload (probably via pg_ctl, and then the postmaster program process creating a server log entry that shows the error (maybe in pgstartup.log, maybe in pg_log, maybe in syslog, maybe in the Windows Event Log)
In practice, the top of that food chain never knows what's happening at the bottom unless something goes so seriously wrong the system is down, and they are forced to drill down into all of these log destinations. That's why a subset of us consider any error message based approaches to GUC guidance a complete waste of time. I won't even address the rest of your comments; you're focusing on trivia around something that just fundamentally isn't useful at all.
My challenge to anyone who things error checking has value for this issue is to demonstrate how that would play out usefully on a mainstream Postgres system like RHEL/CentOS, Debian, or even Windows Put your bogus setting in the config file, activate that config file in a Postgres that looks for the round errors people dislike, and show me how that mistake is made apparent to the user who made it. I've done similar exercises myself, and my guess is that if the system is up at all, those error messages went by completely unnoticed.
-- Greg Smith greg.sm...@crunchydatasolutions.com Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
