From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: adding strndup
In-reply-to: <20191204180457.6yo3dhjsmhlj52ky@alap3.anarazel.de>
References: <20191204144021.GA17976@alvherre.pgsql>
 <20191204180457.6yo3dhjsmhlj52ky@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Wed, 04 Dec 2019 10:04:57 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27819.1575485929.1@sss.pgh.pa.us>
Date: Wed, 04 Dec 2019 13:58:49 -0500
Message-ID: <27820.1575485929@sss.pgh.pa.us>
Precedence: bulk

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