Re: adding strndup

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

In response to

Responses

Browse pgsql-hackers by date

  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