On Thu, Dec 4, 2014 at 3:59 PM, Stephen Frost <sfr...@snowman.net> wrote: > I have a hard time wrapping my head around what a *lot* of our users ask > when they see a given error message, but if our error message is 'you > must have a pear-shaped object to run this command' then I imagine that > a new-to-PG user might think "well, I can't create pear shaped objects > in PG, so I guess this just isn't supported." That's not necessairly > any fault of ours, but I do think "permission denied" reduces the chance > that there's any confusion about the situation.
This is just ridiculous. You're postulating the existing of a person who thinks that a replication role is something that they buy at Wendi's rather than something granted by the database administrator. Give me a break. > I do prefer my version but it's not an unfounded preference. I never said that your preference was unfounded. I said that I disagreed with it. >> The burden for changing existing messages is not high, but your desire >> for a different style is not sufficient to go change half the error >> messages in the backend, or even 20% of them, and I think that 20% is >> a conservative estimate of how many we'd have to change to actually >> achieve what you're talking about here. > > The "different style" is what's in the error style guidelines. I agree > that it could lead to a lot of changes and I don't think we'd need to > change them all in one shot or in one release, in part because of the > burden it would put on translators. As Andres says, that's just plain not true. There is nothing whatsoever in the error guidelines that supports your position on this issue. Reasoning logically, you're saying that this could "could lead to a lot of changes". You're also claiming that it is supported by the message style guidelines. Taken together, these two statements imply that you think that a lot of our current messages are not in conformance with the message style guidelines. But how did all of those non-comformant messages get there, and how is it that no one has ever felt the urge to fix it up until now? After all, it is not as if message style is a topic that never gets discussed here; it does, quite regularly. A more reasonable explanation is that your interpretation of the message style guidelines disagrees with that of other people on this list. > This, in particular, doesn't bother me terribly much- if there's reason > enough for a new code then it's probably because it's something PG > specific enough to justify it. Fair enough. I don't know enough about the merits or demerits of inventing new error codes to have a clear feeling for whether it would be a good idea or not. But that's not the ostensible topic of this thread. >> > If we want to say that role-attribute-related error messages should be >> > "You need X to do Y", then I'll go make those changes, removing the >> > 'permission denied' where those are used and be happier that we're at >> > least consistent, but it'll be annoying if we ever make those >> > role-attributes be GRANT'able rights (GRANT .. ON CLUSTER?) as those >> > errmsg's will then change from "you need X" to "permission denied to do >> > Y". Having the errdetail change bothers me a lot less. >> >> You can't really put "you need X to do Y" in the error message, I >> think. That style is appropriate for an error detail, but not an >> error message. > > I'm utterly confused by this comment. The existing error messages that > I want to change are of the 'you need X to do Y' style (eg: "must be > superuser or have the same role to cancel queries running in other > server processes"). If you're just referring to the 'you' word, then > ok, I agree that it goes against the error style guidelines and it would > really be "need X to do Y", but that wasn't what I was trying to get at > with the above comment. Yes, I was talking about the "you". > I was saying *let's make it consistent* and go > change the existing cases which say "permission denied to create role" > and similar to, instead, say "must have CREATEROLE to create roles". > Today, we're utterly inconsistent. Consistency is a virtue, but not the only one or the highest one. I think that when the rule is something simple, it makes sense to articulate it in the error message, but when the rule gets too complicated to be articulated in brief, then we must give a generic permission denied message and expect the user to go read the manual for more information. Suppose we consider two hypothetical operations, fire-united-states-nukes and punish-recalcitrant-child. The first one is a highly restricted operation, but the criteria are simple enough that they can be stated succinctly: ERROR: must be POTUS to launch US nukes The second operation is far less restricted in terms of who can carry it out, but whether it's allowable in a particular instance is complicated, depending as it does on your relationship to the child in question and the proposed punishment. Parents can probably safely assume they can send their child to their room; and teachers their students to detention; but other punishments may depend on circumstance, and then there are other roles like babysitter, principals, guidance counselor, and substantially-older sibling that each have rules all of their own. It will be impractical to concisely state what will pass muster, so we'd better go with something like: ERROR: permission denied to punish recalcitrant child This is not because it wouldn't be *nice* to give a more specific error message saying exactly what criteria you failed to meet; it's just not really practical to generate an error message for that. But that doesn't mean that we're better off changing the first message to say: ERROR: permission denied to launch US nukes IMHO, that's just pointlessly leaving the user hanging about just how important they have to be when we could have told them the exact rule in fewer characters than it took to be less specific. Now, I realize that you may not agree with this philosophy, but I think that *is* the philosophy behind the current lack of consistency. Counterexamples welcome, of course: if there are inconsistencies that are NOT explained by the principle I just articulated, I might well support revising those cases. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
