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...  (Sean Chittenden <sean@chittenden.org>)
Re: Patch to be verbose about being unable to read ~/.pgpasss...  (Sean Chittenden <sean@chittenden.org>)
Список 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 по дате отправления:

Предыдущее
От: Sean Chittenden
Дата:
Сообщение: Re: Patch to be verbose about being unable to read ~/.pgpasss...
Следующее
От: Sean Chittenden
Дата:
Сообщение: Re: Patch to be verbose about being unable to read ~/.pgpasss...