I've been chewing on the problem described here: http://archives.postgresql.org/pgsql-general/2008-11/msg01220.php
It's not particularly easy to fix without making annoyingly large changes to the API for PQExpBuffer. The best idea I have come up with so far goes like this: * Upon failure to malloc or realloc the buffer for a PQExpBuffer, the pqexpbuffer.c code should release whatever buffer it might have had and set data = pointer to empty, statically allocated string len = 0 maxlen = 0 This is distinguishable from the normal non-error case because maxlen can never be zero in non-error cases. * All subsequent operations except resetPQExpBuffer will do nothing to such a PQExpBuffer. resetPQExpBuffer will attempt to restore the string to "normal" empty status by allocating a new default-size buffer. The result of this would be that in cases such as the one exhibited by Sam Mason, we'd end up with a guaranteed-empty string rather than one that had had subsections unexpectedly removed. Also, we could add out-of-memory checks to callers where it seems important to do so. The main advantage of this approach is that it avoids making ABI breaks (such as would occur if we added an error flag field to PQExpBufferData). The main disadvantage is the need to add explicit error checks to callers anyplace we're not satisfied with just letting the string become empty. The only alternative that I can think of that avoids the latter disadvantage is to allow the pqexpbuffer routines to abort on out-of-memory (ie, printf(stderr) and exit(1)). This seems pretty unpleasant though for functions that are part of libpq's infrastructure. In particular, although we could allow the calling application to override such behavior via some sort of callback hook function, it's far from clear what it could do instead without risking bizarre misbehavior by libpq. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers