From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | bt23nguyent <bt23nguyent(at)oss(dot)nttdata(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Improve the log message output of basic_archive when basic_archive.archive_directory parameter is not set |
Date: | 2023-10-13 02:25:59 |
Message-ID: | 20231013022559.GA1266364@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 26, 2023 at 08:13:45AM +0200, Daniel Gustafsson wrote:
>> On 26 Sep 2023, at 00:20, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>>
>> On Thu, Sep 21, 2023 at 11:18:00AM +0900, bt23nguyent wrote:
>>> -basic_archive_configured(ArchiveModuleState *state)
>>> +basic_archive_configured(ArchiveModuleState *state, char **logdetail)
>>
>> Could we do something more like GUC_check_errdetail() instead to maintain
>> backward compatibility with v16?
>
> We'd still need something exported to call into which isn't in 16, so it
> wouldn't be more than optically backwards compatible since a module written for
> 17 won't compile for 16, or am I missing something?
I only mean that a module written for v16 could continue to be used in v17
without any changes. You are right that a module that uses this new
functionality wouldn't compile for v16. But IMHO the interface is nicer,
too, since module authors wouldn't need to worry about allocating the space
for the string or formatting the message.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2023-10-13 02:41:24 | Re: PostgreSQL domains and NOT NULL constraint |
Previous Message | Andres Freund | 2023-10-13 02:05:22 | Re: Some performance degradation in REL_16 vs REL_15 |