Dave Page wrote:
Doh! Of course it fails. Well, at least this saves me from having to figure out what I missed. BTW, if PQsetClientEncoding fails, which it does, then why would the error come up as a password error?
I think it's because libpq is clever enough to keep the 'real' error rather than just say that the encoding couldn't be set. This makes sense if you think about it, because normally the client encoding will fail to get set if an invaid encoding is chosen - this can only be discovered when the connection is present.
Does that mean that PQsetClientEncoding doesn't change the Postgres errors like other PQ functions?
No. If it gets a real error, then you will see it. Try changing the 'UNICODE' to 'SOMETHINGELSE' and logging in. Note that in this case you may still see 2 sequential error messages - 1 as the master connection is established, then a second for whichever database auto-reopens (and of course, subsequent db opens).
Regards, Dave.