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

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-09-12T15:24:32Z
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.



Commits

  1. walmethods.c/h: Make WalWriteMethod more object-oriented.

  2. walmethods.c/h: Make Walfile a struct, rather than a void *