Horton

Re: [PATCH] Make jsonapi usable from libpq

Jacob Champion <pchampion@vmware.com>

View thread View on postgr.es
From: Jacob Champion <pchampion@vmware.com>
To: "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>
Cc: "daniel@yesql.se" <daniel@yesql.se>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "michael@paquier.xyz" <michael@paquier.xyz>
Date: 2021-06-29T19:26:47Z
Lists: pgsql-hackers 
On Tue, 2021-06-29 at 14:50 -0400, Tom Lane wrote:
> Jacob Champion <pchampion@vmware.com> writes:
> > What would you think about a src/port of asprintf()? Maybe libpq
> > doesn't change quickly enough to worry about it, but having developers
> > revisit stack allocation for strings every time they target the libpq
> > parts of the code seems like a recipe for security problems.
> 
> The existing convention is to use pqexpbuffer.c, which seems strictly
> cleaner and more robust than asprintf.  In particular its behavior under
> OOM conditions is far easier/safer to work with.  Maybe we should consider
> moving that into src/common/ so that it can be used by code that's not
> tightly bound into libpq?

I will take a look. Were you thinking we'd (hypothetically) migrate all
string allocation code under src/common to pqexpbuffer as part of that
move? Or just have it there to use as needed, when nm complains?

--Jacob

Commits

  1. Remove libpq's use of abort(3) to handle mutex failure cases.

  2. Don't use abort(3) in libpq's fe-print.c.

  3. Remove undesirable libpq dependency on stringinfo.c.

  4. Remove arbitrary line length limit for libpq service files.

  5. Use abort() instead of exit() to abort library functions