On Sat, Nov 2, 2013 at 2:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > David Rowley <dgrowle...@gmail.com> writes: > > Tom commited some changes to appendStringInfoVA a few weeks ago which > > allows it to return the required buffer size if the current buffer is not > > big enough. > > > On looking at appendPQExpBufferVA I'm thinking it would be nice if it > could > > make use of the new pvsnprintf function to bring the same potential > > performance improvement in to there too. > > Uh ... it does contain pretty much the same algorithm now. We can't > simply use pvsnprintf there because exit-on-error is no good for > libpq's purposes, so unless we want to rethink that, a certain > amount of code duplication is unavoidable. But they both understand > about C99 vsnprintf semantics now. > > I only just noticed the changes you made to appendPQExpBufferVA(). I had wondered if making pvsnprintf return int instead of size_t and having it return -1 if there are problems, then letting the caller deal with those, but I'm starting to see why you did it the way you did it... There's also quite a few subtle differences with things like max allocation size that would have to be dealt with differently I guess.
I'm low on ideas on how to improve things much around here for now, but for
what it's worth, I did create a patch which changes unnecessary calls to
appendPQExpBuffer() into calls to appendPQExpBufferStr() similar to the
recent one for appendStringInfo and appendStringInfoString.
Regards
David Rowley
regards, tom lane
>
appendPQExpBufferStr_v0.1.patch.gz
Description: GNU Zip compressed data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
