Re: pgConn.cpp.patch

-----Original Message-----
From: Adam H. Pendleton [mailto:fmonkey(at)fmonkey(dot)net]
Sent: 25 June 2003 15:51
To: Dave Page
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: [pgadmin-hackers] pgConn.cpp.patch


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.