Re: pg_restore error message - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_restore error message
Date
Msg-id 20200509073908.GK11539@paquier.xyz
Whole thread Raw
In response to Re: pg_restore error message  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: PG 13 release notes, first draft
Next
From: Michael Paquier
Date:
Subject: Re: Strange decreasing value of pg_last_wal_receive_lsn()