From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: adding strndup |
Date: | 2019-12-04 18:58:49 |
Message-ID: | 27820.1575485929@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-12-04 19:05:01 | Re: adding strndup |
Previous Message | Masahiko Sawada | 2019-12-04 18:50:59 | Re: [HACKERS] Block level parallel vacuum |