Adrian Klaver <adrian.klaver@gmail.com> writes:
> I believe the problem, as Hiroshi Saito pointed out, is that the client
> encoding is being set on Windows before the connection is attempted and
> that it is picking the wrong one. Per his post pgAdmin and JDBC are
> probably just starting with UTF8 and that is why they succeed. At this
> point I don't know how to get around that.
AFAIK the only way to get the mentioned error message (about "no
pg_hba.conf entry") from this kind of problem is if the DBA is listing
user names directly in pg_hba.conf. Since there is no encoding
conversion active this early in backend startup, non-ASCII user names can
only work if the encoding used in pg_hba.conf matches what is arriving
from the client.
Possible solution: make *two* (or more) entries in pg_hba.conf, one in
each encoding that clients might be using. This is probably
unmaintainable though, particularly when using Windows editors which are
almost certainly going to think they know more than you do about
encodings.
Better idea: refrain from mentioning specific usernames in pg_hba.conf.
Usually, anything you might want to do that way can be done better in
other ways. For instance, make use of the CONNECT privilege if you're
running a release new enough to have it.
By and large, though, non-ASCII user names are going to be problematic
anyway --- even if you got past the pg_hba.conf check, I think you might
just get a "no such user" failure when the client sends the name in an
encoding that doesn't match what's in the system catalog. This is an
area that's known to need work.
regards, tom lane
