On 6/22/15 9:00 AM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> On 6/19/15 10:35 AM, Tom Lane wrote:
>>> 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.
>
>> Could we return a HINT? Or is that part of the same string?
>
> Unfortunately no, there's no out-of-band additions possible here.
>
> It strikes me that my argument above is too myopic, because I was only
> thinking about cases where the client can plausibly do an interactive
> prompt for password. If it cannot (eg, psql --no-password, or perhaps
> the process has no controlling terminal) then what you're going to see
> is whatever message libpq returns. So if people feel that this message
> is not clear enough, maybe it's time to break compatibility and change it.
>
> I do not follow Craig's argument that this is somehow connected to the
> wire protocol version. It's not; it's part of the libpq-to-client API.
> If there ever is a protocol version 4, it will almost certainly not
> trigger significant changes in that API --- there might be additions,
> but not incompatible changes. So if we think we can't change that
> message now, then face it, we never will.
Yeah, looking at Craig's extensive review, it seems most of those places
wouldn't actually prompt for a password, so I think it's best that we
just change this.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
