Re: Reasons not to like asprintf

I wrote:
> Stephen Frost <sfrost@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 front-end we exit, while on the
>> back-end we elog(ERROR).  I'm guessing that's a pipe-dream,

> It's not really --- we could make it happen with a single source-file in
> libpgcommon, with a few #ifdef FRONTENDs, similarly to exec.c for
> instance.  I'm not entirely sure that it's worth the trouble, since once
> you take away the error and memory management there's not much left of
> these functions; so the #ifdefs might end up being most of the code.
> I'm going to go code it shortly, and we'll find out.

Attached is a draft, which compiles though I've not yet actually tested it.
It seems pretty reasonable as far as readability goes.  A couple of notes:

1. I omitted pvsprintf(), which we don't actually use anywhere anyway.
I don't see any way to implement that API without va_copy, which is one
of the main things I'm trying to get rid of.  Since we've never needed
a va_args variant in stringinfo.c in all the years we've had that, I
think we can get away with omitting it here.

2. The file includes utils/memutils.h, which I'm not 100% sure is safe
to include in the FRONTEND case.  This is so that it can refer to
MaxAllocSize.  If it turns out that that causes build problems on some
platforms, we could use some more ad-hoc way to define the limit (maybe
just INT_MAX/4?), or we could move the definition of MaxAllocSize into
palloc.h.

Barring objections, I'll push forward with replacing the existing code
with this.

            regards, tom lane