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
-
walmethods.c/h: Make WalWriteMethod more object-oriented.
- ebfb814f7ce0 16.0 landed
-
walmethods.c/h: Make Walfile a struct, rather than a void *
- 4fd14794945e 16.0 landed