Thread: Max Query length string

Hi,

I've been mulling over the idea of using stringinfo for psql, but I don't
think that it's such a good idea, because it means that I would be linking
stuff from the backend sub-tree into client tools.  Stringinfo is a module
which implements an expandable string buffer which already exists in
src/backend/lib.  I have required this for psql, and initially wrote my own.
Bruce mentioned that I should look at stringinfo, which I did, and it seems
to fill the requirements just fine.
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.  I don't
know if there are any dependencies at the moment, but my first instinct
would be to try to prevent any from creeping in.

Ideas, thoughts...


MikeA

"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