From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jacob Champion <pchampion@vmware.com>
Cc: michael@paquier.xyz <michael@paquier.xyz>
Cc: daniel@yesql.se <daniel@yesql.se>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Make jsonapi usable from libpq
Date: Tue, 29 Jun 2021 14:50:20 -0400
Message-ID: <497374.1624992620@sss.pgh.pa.us> (raw)
In-Reply-To: <c475057da66fdc5ae707a89f5b44dd8508b86f7e.camel@vmware.com>
References: <a250d475ba1c0cc0efb7dfec8e538fcc77cdcb8e.camel@vmware.com>
<YNQedHwheUaTnnGt@paquier.xyz>
<daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com>
<YNZ2mnsbDVJQrA/a@paquier.xyz>
<c475057da66fdc5ae707a89f5b44dd8508b86f7e.camel@vmware.com>
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?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pchampion@vmware.com, michael@paquier.xyz, daniel@yesql.se
Subject: Re: [PATCH] Make jsonapi usable from libpq
In-Reply-To: <497374.1624992620@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox