Re: walmethods.c/h are doing some strange things

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: walmethods.c/h are doing some strange things
Date: 2022-09-12 15:24:32
Message-ID: b72eb948-a239-6467-6817-d70e5fa7d3d9@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02.09.22 17:52, Robert Haas wrote:
> Attached are a couple of hastily-written patches implementing this.
> There might be good arguments for more thoroughly renaming some of the
> things these patches touch, but I thought that doing any more renaming
> would make it less clear what the core of the change is, so I'm
> posting it like this for now. One thing I noticed while writing these
> patches is that the existing code isn't very clear about whether
> "Walfile" is supposed to be an abstraction for a pointer to the
> implementation-specific struct, or the struct itself. From looking at
> walmethods.h, you'd think it's a pointer to the struct, because we
> declare typedef void *Walfile. walmethods.c agrees, but receivelog.c
> takes a different view, declaring all of its variables as type
> "Walfile *". This doesn't cause a compiler error because void * is
> just as interchangeable with void ** as it is with DirectoryMethodFile
> * or TarMethodFile *, but I think it is clearly a mistake, and the
> approach I'm proposing here makes such mistakes more difficult to
> make.

This direction does make sense IMO.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-09-12 15:28:34 Re: Can we avoid chdir'ing in resolve_symlinks() ?
Previous Message Stephen Frost 2022-09-12 15:22:31 Re: Add tracking of backend memory allocated to pg_stat_activity