Re: pgConn.cpp.patch - Mailing list pgadmin-hackers

From Dave Page
Subject Re: pgConn.cpp.patch
Date
Msg-id 03AF4E498C591348A42FC93DEA9661B844B137@mail.vale-housing.co.uk
Whole thread Raw
In response to pgConn.cpp.patch  (Adam H.Pendleton <fmonkey@fmonkey.net>)
List pgadmin-hackers
 
-----Original Message-----
From: Adam H. Pendleton [mailto:fmonkey@fmonkey.net]
Sent: 25 June 2003 15:51
To: Dave Page
Cc: pgadmin-hackers@postgresql.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.
 
 

pgadmin-hackers by date:

Previous
From: "Adam H. Pendleton"
Date:
Subject: Re: pgConn.cpp.patch
Next
From: Jean-Michel POURE
Date:
Subject: Localisation strings