Re: Patch to be verbose about being unable to read ~/.pgpasss...
От | Sean Chittenden |
---|---|
Тема | Re: Patch to be verbose about being unable to read ~/.pgpasss... |
Дата | |
Msg-id | 20030620233112.GD84329@perrin.int.nxad.com обсуждение исходный текст |
Ответ на | Re: Patch to be verbose about being unable to read ~/.pgpasss... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch to be verbose about being unable to read ~/.pgpasss...
|
Список | pgsql-patches |
> > Would you like me to add an interface that'd allow stderr to be > > redirected in the case of defaultNoticeProcessor()? > > No, the application is supposed to set a notice processor if it > doesn't want stuff going to stderr. I don't think that stuff needs > to be redesigned. Ehh... I'd say it's kinda broken as a logging interface in its current encarnation. Whoever does the autoconf magic should test for stdarg.h. Since we're on the verge of a minor version change, might not be a bad time to adjust this. There should be no source code incompatabilities introduced in this change, but things will have to be recompiled as the function ABI has changed. > > We can stat a file that is owned by root and not readable to the > > user. In such a case, because the user isn't able to read the > > file, all libpq applications will fail making it effectively > > possible for the system admin to shut off all applications that > > use libpq. > > Hardly, since the user can simply remove or rename the file. It's > in his home directory, remember? (If he can't write his home > directory then whether libpq works is the least of his troubles.) *shrug* Whatever floats whoever's boat, I'm easy, just playing devils advocate. Now that I think about it though, there's no graceful way to get PasswordFromFile() to tell the application to abort and nor should it. I think the warnings and bailing out of PasswordFromFile() is sufficient. Comments on the revised patch? -sc -- Sean Chittenden
Вложения
В списке pgsql-patches по дате отправления: