Re: Reasons not to like asprintf - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reasons not to like asprintf
Date
Msg-id 4124.1382470830@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reasons not to like asprintf  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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>)
List 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 by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Commitfest II CLosed
Next
From: Stephen Frost
Date:
Subject: Re: Reasons not to like asprintf