"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> What I'd like to do is use the expandable buffer that I wrote for psql, and
> any other client-side utils that require it; and then use stringinfo for
> anything new that requires an expanable buffer in the backend (this will
> happen anyway, stringinfo's here to stay). This removes any dependency
> between the client-side and server-side components of the system.
There is precedent for sharing low-level code between frontend and
backend, with maybe a #define or two to handle differences like
palloc <=> malloc. See dllist.c and some of the MULTIBYTE routines that
get included into frontend libpq. The main restriction is that you
can't really report any errors from such code, since error handling in
the backend is via elog() which won't exist in clients. However,
reporting errors from a client-side library is going to be ticklish
anyway --- if you try to do anything more than return an error-code
return value, some clients will be unhappy with you. So it's not as big
a restriction as it might appear.
In short, I'd suggest seeing whether you can't make stringinfo portable
to a frontend environment; and then merge any good ideas you had in your
code into it (or vice versa if that seems easier). Keeping two
different modules that accomplish more or less the same thing doesn't
strike me as a win.
regards, tom lane