Re: Patch to be verbose about being unable to read
От | Tom Lane |
---|---|
Тема | Re: Patch to be verbose about being unable to read |
Дата | |
Msg-id | 17716.1056117675@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch to be verbose about being unable to read (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Patch to be verbose about being unable to read ~/.pgpasss...
|
Список | pgsql-patches |
Peter Eisentraut <peter_e@gmx.net> writes: > Sean Chittenden writes: >> Howdy. Quick chump patch: if libpq finds a ~/.pgpass but can't stat >> it, print something to stderr letting the user know. If someone went >> out of their way to put a .pgpass file in place, if they can't read >> it, it seems worth while to alert them to the fact that it's not being >> used (ex: root creates a .pgpass file but forgets to chown it). > You cannot assume that stderr is meaningful in all applications using > libpq. (Consider PHP.) I think you need to report this using the normal > error reporting mechanism. But it's not an error; we must not fail the connection attempt just because of this. I'd suggest using the NOTICE mechanism, except that during connection setup the client app has not yet had a chance to set a notice processor, so Peter's objection still holds. On the whole, I'm not sure we have a problem we need to fix there. If .pgpass isn't readable, it's not going to take that long for the user to figure it out. OTOH --- there already is a print-to-stderr in the code for the case where .pgpass exists and has insecure permissions. Taking Peter's complaint into account, I wonder whether we shouldn't make that case a hard error (connect failure) to ensure that the user notices the problem and does something about it promptly. IIRC, the postmaster refuses to start if $PGDATA has insecure permissions, so there's precedent. regards, tom lane
В списке pgsql-patches по дате отправления: