From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: adding strndup
Date: Wed, 04 Dec 2019 13:58:49 -0500
Message-ID: <27820.1575485929@sss.pgh.pa.us> (raw)
In-Reply-To: <20191204180457.6yo3dhjsmhlj52ky@alap3.anarazel.de>
References: <20191204144021.GA17976@alvherre.pgsql>
<20191204180457.6yo3dhjsmhlj52ky@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2019-12-04 11:40:21 -0300, Alvaro Herrera wrote:
>> I think this should be pretty uncontroversial, but wanted to give a
>> heads-up outside that thread. I attach the patch here for completeness.
> I'd just provide pnstrdup() in the frontend, without adding strndup().
+1 --- seems like a bunch more mechanism than is warranted. Let's
just open-code it in pnstrdup. We can rely on strnlen, since that's
already supported, and there's not much more there beyond that.
> I also see no point in adding both pnstrdup() and pg_strndup(). I'm fine
> with moving towards pg_strndup(), but then we just ought to remove
> pnstrdup().
There's a fair number of uses of pnstrdup in the backend. While it
wouldn't be too painful to rename them, I'm not sure I see the point.
(What I'd really argue for, if we did rename, is "pstrndup".)
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, andres@anarazel.de, alvherre@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: adding strndup
In-Reply-To: <27820.1575485929@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