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 | 27266.1056310355@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...
Re: Patch to be verbose about being unable to read ~/.pgpasss... |
Список | pgsql-patches |
Sean Chittenden <sean@chittenden.org> writes: > Um, I said it would change the ABI and I said as much in my previous > post. The ABI is only the smaller part of the problem; you'd be forcing people to change their source code, in a rather nonobvious way. > it is code compatible provided people aren't using any % > escape strings in their error messages (if there aren't any format > strings, there won't be any need to modify the program), And if there aren't any format strings, then we don't need to change the interface. I don't see your point at all. You cannot make use of the added functionality without breaking client applications. I could envision a helper procedure, known only within libpq, that has a signature like formatNotice(PGconn* conn, const char *fmtstring, ...) and encapsulates the work needed to handle a format string. But I see no reason to push that work out to client applications. regards, tom lane
В списке pgsql-patches по дате отправления: