Alvaro Herrera writes:
>> I can get behind that ... it makes the patch a lot smaller.
> Here it is.
LGTM.
> I noticed that ECPG's copy was setting errno. I had forgot to do that
> in my previous patch, but on second look, malloc failure already sets
> it, so doing it again is pointless.
Right
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
> > 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 m
Andres Freund 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,
ized
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
Alvaro Herrera writes:
> 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.
Grep
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.
--
Álvaro Herrera
