From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_restore error message |
Date: | 2020-05-09 07:39:08 |
Message-ID: | 20200509073908.GK11539@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 08, 2020 at 07:45:16PM -0400, Alvaro Herrera wrote:
> Yeah, there's a lot of frontend code that uses free() instead of
> pg_free(). There are too many of these that worrying about a single one
> would not improve things much. I guess we could convert them all, but I
> don't see much point.
Doing a hard switch would have the disadvantage to create more
problems when back-patching. Even if such conflicts would be I guess
simple enough to address, that's less to worry about. I think however
that there is a point in switching to a more PG-like API if reworking
an area of the code for a new feature or a refactoring, but this is a
case-by-case judgement usually.
>> 2. %m, is a format to parameter, right?
>> But what parameter? Both fatal call, do not pass this parameter, or is
>> it implied?
>
> %m is an implied "strerror(errno)", implemented by our snprintf
> replacement.
Originally, %m is a glibc extension, which has been added recently in
our port in src/port/snprintf.c as of d6c55de.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-05-09 08:48:07 | Re: Strange decreasing value of pg_last_wal_receive_lsn() |
Previous Message | Fabien COELHO | 2020-05-09 06:54:10 | Re: Another modest proposal for docs formatting: catalog descriptions |