From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: superuser() shortcuts |
Date: | 2014-12-04 21:19:08 |
Message-ID: | 20141204211908.GA21964@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-12-04 15:59:17 -0500, Stephen Frost 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.
I've a hard time taking this comment seriously. If can't believe that
you think that comment bears relation to the error message we're
discussing.
> > The answer is that there really
> > *isn't* any additional information conveyed by your proposal rewrite;
>
> To be sure it's clear, I *don't* agree with this. You and I don't see
> any additional information in it because we're familiar with the system
> and know all about role attributes, the GRANT system, and everything
> else. I'm not looking to change the error message because it's going to
> make it clearer to you or to me or to anyone else on this list though.
> The "different style" is what's in the error style guidelines.
I think you're vastly over-interpreting the guidelines because that
happens to suite your position.
None of the current error message violates any of:
> The primary message should be short, factual, and avoid reference to
> implementation details such as specific function names. "Short" means
> "should fit on one line under normal conditions". Use a detail message
> if needed to keep the primary message short, or if you feel a need to
> mention implementation details such as the particular system call that
> failed. Both primary and detail messages should be factual. Use a hint
> message for suggestions about what to do to fix the problem, especially
> if the suggestion might not always be applicable.
And I don't for a second buy your argument that the permissions involved
are an implemementation detail.
If you say that you like the new message better because it's more
consistent or more beautiful I can buy that. But don't try to find
justifications in guidelines when they don't contain that.
> > I just don't understand why you want to pointlessly tinker with this.
>
> Because I don't feel it's pointless to improve the consistency of the
> error messaging and I don't like that it's inconsistent today.
Then please do so outside of patches/threads that do something pretty
much unrelated.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-12-04 21:39:02 | Re: libpq pipelining |
Previous Message | Alvaro Herrera | 2014-12-04 21:15:07 | Re: [COMMITTERS] pgsql: Support frontend-backend protocol communication using a shm_mq. |