From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: appendPQExpBufferVA vs appendStringInfoVA |
Date: | 2013-11-02 01:47:51 |
Message-ID: | CA+TgmoZdguoOoaQ_iraZNYS7PyhLQvnBQ0PN3ky-BzRMoPWQWQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 1, 2013 at 9:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Rowley <dgrowleyml(at)gmail(dot)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 have often found it frustrating that we have appendStringInfo* for
the backend and appendPQExpBuffer* for the frontend. It'd be nice to
have one API that could be used in both places, somehow. There seems
to be a lot of interest (including on my part) in writing code that
can be compiled in either environment.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David Johnston | 2013-11-02 02:57:25 | Re: Feature request: Optimizer improvement |
Previous Message | Tom Lane | 2013-11-02 01:27:53 | Re: appendPQExpBufferVA vs appendStringInfoVA |