From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pg(at)heroku(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: PQclientEncoding() returns -1, resulting in possible assertion failure in psql |
Date: | 2013-12-08 23:17:35 |
Message-ID: | 20131209.081735.1321847791044178990.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> branches. I would argue however that the documentation nowhere
> suggests that PQclientEncoding can return a bogus encoding ID,
> so this is more likely to be a bug fix than a new bug for other
> programs as well. Also, it looks to me like there are probably
This sounds like a little bit unfair argument. The libpq documentation
is pretty sloppy for the error case for other PQ* as well. For
example, look at the PQdb document:
PQdb
Returns the database name of the connection.
char *PQdb(const PGconn *conn);
This says nothing about when the connection is bad. Reality is PQdb
returns NULL in the case. But are we allowed to change PQdb returns
say, "template1" when the connection is bad because the doc says
nothing about error case?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | jruan | 2013-12-09 02:31:53 | BUG #8670: Password messed up |
Previous Message | Peter Geoghegan | 2013-12-08 20:36:44 | Re: PQclientEncoding() returns -1, resulting in possible assertion failure in psql |