Re: Patch to be verbose about being unable to read ~/.pgpasss...
От | Tom Lane |
---|---|
Тема | Re: Patch to be verbose about being unable to read ~/.pgpasss... |
Дата | |
Msg-id | 19478.1056133645@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch to be verbose about being unable to read ~/.pgpasss... (Sean Chittenden <sean@chittenden.org>) |
Ответы |
Re: Patch to be verbose about being unable to read ~/.pgpasss...
|
Список | pgsql-patches |
Sean Chittenden <sean@chittenden.org> writes: > stderr is hooked up to the error logs under Apache, which is the > normal error reporting mechanism. I thought about adding a test to > see if stderr is writable, but given that better than 99% of the time > it will be, I didn't see the point, esp since the above case regarding > the permissions, doesn't. If you are inside a GUI application, it's entirely likely that stderr is hooked up to /dev/null. I think Peter's complaint has great force --- libpq has no business assuming it's okay to write on stderr. The entire reason we provided a notice-processor hook is to get away from that assumption. >> But it's not an error; we must not fail the connection attempt just >> because of this. > Agreed, though one train of thought is that if someone did put a > .pgpass file in place that isn't readable, it should be known that > their efforts are being wasted in vein. Yeah, in fact I've been reconsidering that. If we fail to stat the file, we should just return quietly; but if we can stat it but not open it, it's reasonable to assume there's something wrong that ought to be fixed. It's difficult to say that this shouldn't be a hard error if you accept my suggestion that world readability should be an error. If we do take that viewpoint then the problem goes away, since we can just report all the reportable conditions as connection-failure messages. regards, tom lane
В списке pgsql-patches по дате отправления: