Re: Time to get rid of PQnoPasswordSupplied?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Jun 14, 2015 at 11:34 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>> I frequently see users confused by one of our more common and less
>> clear error messages:
>>
>> fe_sendauth: no password supplied

> I've never seen this error message, but I'm not opposed to improving
> it in some way.

The reason you don't see it is that psql and other clients take special
action (ie, prompt you for a password) instead of actually showing you
that error string when it's returned by libpq.

The reason the string is considered part of libpq's external API is that
once upon a time, strcmp() to that particular string value was the only
way for clients to realize that prompt-for-a-password was the appropriate
response. Nowadays you're supposed to use PQconnectionNeedsPassword()
instead.

Apparently, Craig is responsible for some client-side code that has never
heard of either convention and just fails instead of prompting for a
password. So improving that might be something to put on somebody's
to-do list.

However, the question for us is whether there are any clients that still
use strcmp() to the PQnoPasswordSupplied literal, and so would be broken
if we change it. My guess is yes, but I'd still be on board with
replacing the string with something more message-style-guide-compliant
(and localizable). PQnoPasswordSupplied has been marked as deprecated
since 2007.

On the other hand, you could argue that improving the string is going
to break clients that do the right thing (even if klugily) in order
to help clients that are doing the wrong thing (ie, failing without
offering the opportunity to enter a password). Ideally no client app
would ever show this message to users and so its readability would not
matter.

regards, tom lane