Re: Reasons not to like asprintf

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reasons not to like asprintf
Дата
Msg-id 4124.1382470830@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Reasons not to like asprintf  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Reasons not to like asprintf  (Stephen Frost <sfrost@snowman.net>)
Re: Reasons not to like asprintf  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Reasons not to like asprintf  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
... BTW, another reason to choose identical APIs for frontend and backend
versions of these functions is that it greatly eases use of them in shared
frontend/backend code.  As I notice somebody has *already done* in
common/relpath.c.   I'm not exactly sure how those psprintf calls are
working at all in frontend builds.  Maybe they aren't quite, and that has
something to do with the failures on anole?

In order to avoid having to clutter stuff like that with #ifdef FRONTENDs,
I'm now thinking we should use exactly the same names for the frontend and
backend versions, ie psprintf() and pvsprintf().  The main reason for
considering a pg_ prefix for the frontend versions was to avoid cluttering
application namespace; but it's already the case that we don't expect
libpgcommon to be namespace clean.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Commitfest II CLosed
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Reasons not to like asprintf