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

From Robert Haas
Subject Re: superuser() shortcuts
Date
Msg-id CA+TgmoZTVF6JJAaMQcsBP22POmX7emDLJLXt=Gmv7H1vjZid2Q@mail.gmail.com
Whole thread Raw
In response to Re: superuser() shortcuts  (Stephen Frost <sfrost@snowman.net>)
Responses Re: superuser() shortcuts  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Dec 2, 2014 at 2:35 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Tue, Dec 2, 2014 at 11:29 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> > It includes the actual error message, unlike what we have today which is
>> > guidence as to what's required to get past the permission denied error.
>> >
>> > In other words, I disagree that the same amount of information is being
>> > conveyed.
>>
>> So, you think that someone might see the message "must be superuser or
>> replication role to use replication slots" and fail to understand that
>> they have a permissions problem?
>
> I think that the error message about a permissions problem should be
> that there is a permissions problem, first and foremost.

I can't disagree with that, but it's not like the current message is:

ERROR: I ran into some kind of a problem but I'm not going to tell you
what it is for a long time OK I guess that's enough well actually you
see there is a problem and it happens to do have to do with
permissions and in particular that they are denied.

It's pretty clear that the current message is complaining about a
permissions problem, so the fact that it doesn't specifically include
the words "permission" and "denied" doesn't bother me.  Let me ask the
question again: what information do you think is conveyed by your
proposed rewrite that is not conveyed by the current message?

> We don't say 'You must have SELECT rights on relation X to select from
> it.' when you try to do a SELECT that you're not allowed to.  We throw a
> permissions denied error.  As pointed out up-thread, we do similar
> things for other cases of permissions denied and even beyond permission
> denied errors we tend to match up the errmsg() with the errcode(), which
> makes a great deal of sense to me and is why I'm advocating that
> position.

I don't thing that trying to match up the errmsg() with the errcode()
is a useful exercise.  That's just restricting the ways that people
can write error messages in a way that is otherwise unnecessary.  The
errmsg() and errcode() have different purposes; the former is to
provide a concise, human-readable description of the problem, and the
latter is to group errors into categories so that related errors can
be handled programmatically.  They need not be, and in many existing
cases are not, even vaguely similar; and the fact that many of our
permission denied errors happen to use that phrasing is not a
sufficient justification for changing the rest unless the new phrasing
is a bona fide improvement.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: How about a option to disable autovacuum cancellation on lock conflict?
Next
From: Andres Freund
Date:
Subject: Re: Turning recovery.conf into GUCs