On 10/22/13, 3:40 PM, Tom Lane wrote:
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
Peter Eisentraut pete...@gmx.net writes:
On 10/22/13, 3:40 PM, Tom Lane wrote:
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
On Thu, Oct 24, 2013 at 2:18 PM, Peter Eisentraut pete...@gmx.net wrote:
On 10/22/13, 3:40 PM, Tom Lane wrote:
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()
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 24, 2013 at 2:18 PM, Peter Eisentraut pete...@gmx.net wrote:
While this is attractive, the same logic would suggest that we rename
pg_malloc() to palloc(), and that sounds wrong. The frontend and
backend functions do have different freeing
On 10/22/2013 11:06 PM, Tom Lane wrote:
Attached is a draft, which compiles though I've not yet actually tested it.
nprinted = vsnprintf(buf, len, fmt, args);
Assert(buf[len - 1] == '\0');
The assert may fire if len INT_MAX and the system returns with errno
== EOVERFLOW,
I wrote:
I have a lot of other gripes about this whole patch, but they can
wait till tomorrow.
The other big thing I don't like about this patch is that adopting
asprintf() as a model was not any better thought-out than the
portability considerations were. It's a bad choice because:
1.
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
In short, I want to change pg_asprintf to return the malloc'd buffer
as its function result. This probably means we should change the
function name too, since the allusion to asprintf is completely useless
if we do that. I'm thinking pg_psprintf
Stephen Frost sfr...@snowman.net writes:
Sounds reasonable, and I haven't got a better name, but I'm trying to
figure out why psprintf hasn't got the same issues which you mention in
your other thread (eg: depending on vsnprintf to return the would-be
result size).
It does, though not
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Sounds reasonable, and I haven't got a better name, but I'm trying to
figure out why psprintf hasn't got the same issues which you mention in
your other thread (eg: depending on vsnprintf to return the would-be
Stephen Frost sfr...@snowman.net writes:
I agree that exit/Assert-or-elog is the right API here. I wonder if
it'd be reasonable or worthwhile to try and actually make that happen-
that is to say, we really do only have one implementation for both
front-end and back-end here, but on the
... 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
... 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
Tom Lane wrote:
... 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
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
... 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
I wrote:
Stephen Frost sfr...@snowman.net writes:
I agree that exit/Assert-or-elog is the right API here. I wonder if
it'd be reasonable or worthwhile to try and actually make that happen-
that is to say, we really do only have one implementation for both
front-end and back-end here, but on
15 matches
Mail list logo
