Re: superuser() shortcuts - Mailing list pgsql-hackers

On Thu, Dec 4, 2014 at 3:59 PM, Stephen Frost <sfrost@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