Date: Wed, 4 Dec 2019 16:05:01 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: adding strndup
Message-ID: <20191204190501.GA29287@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <27820.1575485929@sss.pgh.pa.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2019-Dec-04, Tom Lane wrote:

> 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 can get behind that ... it makes the patch a lot smaller.  I'm gonna
send an updated version in a jiffy.

> > 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".)

*shrug*  I also looked for pstrndup() first.  And Peter E also in
https://postgr.es/m/1339713732.11971.79.camel@vanquo.pezone.net
submitted an implementation of pstrndup().  I'm not opposed to renaming
it, but I hesitate to do it at the same time as putting it in pgport.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services