Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyJVN-0004ju-3r for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Jun 2021 19:34:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lyJVL-0003SE-UW for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Jun 2021 19:34:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyJVL-0003Rc-My for pgsql-hackers@lists.postgresql.org; Tue, 29 Jun 2021 19:34:43 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyJVB-0002oM-IZ for pgsql-hackers@postgresql.org; Tue, 29 Jun 2021 19:34:43 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 15TJYTV9499674; Tue, 29 Jun 2021 15:34:29 -0400 From: Tom Lane To: Jacob Champion cc: "daniel@yesql.se" , "pgsql-hackers@postgresql.org" , "michael@paquier.xyz" Subject: Re: [PATCH] Make jsonapi usable from libpq In-reply-to: References: <497374.1624992620@sss.pgh.pa.us> Comments: In-reply-to Jacob Champion message dated "Tue, 29 Jun 2021 19:26:47 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <499671.1624995269.1@sss.pgh.pa.us> Date: Tue, 29 Jun 2021 15:34:29 -0400 Message-ID: <499672.1624995269@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jacob Champion writes: > On Tue, 2021-06-29 at 14:50 -0400, Tom Lane wrote: >> 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? Actually, I'd forgotten that the PQExpBuffer functions are already exported by libpq, and much of our frontend code already uses them from there. So we don't really need to move anything unless there's a call to use this code in clients that don't use libpq, which are a pretty small set. Also, having them be available both from libpq.so and from libpgcommon.a would be a tad problematic I think; it'd be hard to tell which way the linker would choose to resolve that. regards, tom lane