From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: adding strndup |
Date: | 2019-12-04 18:04:57 |
Message-ID: | 20191204180457.6yo3dhjsmhlj52ky@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-12-04 11:40:21 -0300, Alvaro Herrera wrote:
> I just proposed in
> https://postgr.es/m/0191204143715.GA17312@alvherre.pgsql the addition of
> strndup() to our src/port.
>
> I think this should be pretty uncontroversial, but wanted to give a
> heads-up outside that thread. I attach the patch here for completeness.
Well, I personally think it's a bad idea to add further implementations
for functions that are in standar libraries on some systems. Especially,
but not exclusively, when made available for frontend code, where it's
not unlikely that there might be other applications having their own
implementations of strndup/whatever.
Besides that reason, I think AC_REPLACE_FUNCS is just a bad mechanism,
that yields fragmented source code and needs to implemented differently
for windows. The code additionally often will also be badly optimized
in general, due to tiny translation units without relevant functions
having knoweldge about each other.
I'd just provide pnstrdup() in the frontend, without adding strndup().
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().
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-12-04 18:47:07 | Re: backup manifests |
Previous Message | Rushabh Lathia | 2019-12-04 18:01:37 | Re: backup manifests |