Re: adding strndup
От | Alvaro Herrera |
---|---|
Тема | Re: adding strndup |
Дата | |
Msg-id | 20191204190501.GA29287@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: adding strndup (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: adding strndup
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: