Обсуждение: pgConn.cpp.patch
This patch fixes a bug in the error reporting of the new connection dialog when setting the database encoding. ahp
Вложения
> -----Original Message-----
> From: Adam H.Pendleton [mailto:fmonkey@fmonkey.net]
> Sent: 25 June 2003 03:02
> To: pgadmin-hackers@postgresql.org
> Subject: [pgadmin-hackers] pgConn.cpp.patch
>
>
> This patch fixes a bug in the error reporting of the new connection
> dialog when setting the database encoding.
Hi Adam,
I don't believe this patch is correct. PQsetClientEncoding returns 0 on
success and -1 on failure [1], therefore !PQsetClientEncoding is true
upon success.
- if (PQsetClientEncoding(conn, "UNICODE"))
+ if (!PQsetClientEncoding(conn, "UNICODE"))
wxLogError(wxT("%s"), wxString(PQerrorMessage(conn),
wxConvUTF8).c_str());
Patch NOT applied.
Regards, Dave.
[1]
http://www.postgresql.org/docs/view.php?version=7.3&idoc=0&file=multibyt
e.html
Dave Page wrote:
if (PQsetClientEncoding(conn, "SQL_ASCII"))
wxLogError(wxT("%s"), PQerrorMessage(conn));
causes wxLogError to be run, if there was an error in the connection. For example, try connecting to a postgres database with an incorrect password. You will get *two* password incorrect dialogs. The first is displayed by the above code.
ahp
The docs may say that, but I can tell you that:-----Original Message----- From: Adam H.Pendleton [mailto:fmonkey@fmonkey.net] Sent: 25 June 2003 03:02 To: pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] pgConn.cpp.patch This patch fixes a bug in the error reporting of the new connection dialog when setting the database encoding.Hi Adam, I don't believe this patch is correct. PQsetClientEncoding returns 0 on success and -1 on failure [1], therefore !PQsetClientEncoding is true upon success.
if (PQsetClientEncoding(conn, "SQL_ASCII"))
wxLogError(wxT("%s"), PQerrorMessage(conn));
causes wxLogError to be run, if there was an error in the connection. For example, try connecting to a postgres database with an incorrect password. You will get *two* password incorrect dialogs. The first is displayed by the above code.
ahp
-----Original Message-----
From: Adam H. Pendleton [mailto:fmonkey@fmonkey.net]
Sent: 25 June 2003 14:40
To: Dave Page
Cc: pgadmin-hackers@postgresql.org
Subject: Re: [pgadmin-hackers] pgConn.cpp.patchDave Page wrote:
The docs may say that, but I can tell you that:
if (PQsetClientEncoding(conn, "SQL_ASCII"))
wxLogError(wxT("%s"), PQerrorMessage(conn));
causes wxLogError to be run, if there was an error in the connection. For example, try connecting to a postgres database with an incorrect password. You will get *two* password incorrect dialogs. The first is displayed by the above code.
Yes, this is because the PQsetClientEncoding fails because the connection failed. I've changed the preceeding code to:
// Set client encoding to Unicode/Ascii
if (PQstatus(conn) == CONNECTION_OK)
{
if (PQstatus(conn) == CONNECTION_OK)
{
#if wxUSE_UNICODE
wxLogInfo(wxT("Setting client_encoding to 'UNICODE'"));
...
...
which takes care of it.
Regards, Dave.
Dave Page wrote:
ahp
Yes, this is because the PQsetClientEncoding fails because the connection failed. I've changed the preceeding code to:
// Set client encoding to Unicode/Ascii
if (PQstatus(conn) == CONNECTION_OK)
{
if (PQstatus(conn) == CONNECTION_OK)
{
#if wxUSE_UNICODE
wxLogInfo(wxT("Setting client_encoding to 'UNICODE'"));
...
...
which takes care of it.
Regards, Dave.
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? Does that mean that PQsetClientEncoding doesn't change the Postgres errors like other PQ functions?ahp
-----Original Message-----Dave Page wrote:
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
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.