> On 17 Apr 2025, at 01:12, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Michael Paquier <mich...@paquier.xyz> writes: >> On Wed, Apr 16, 2025 at 04:19:02PM +0200, Daniel Gustafsson wrote: >>> Agreed, while it's perfectly safe today the end method should not make >>> assumptions about the use of the private_data pointer upon return and should >>> leave it set to NULL. > >> Indeed. I was just looking at applying what Alexander has sent >> because what EndCompressorZstd() not doing what the other methods do >> makes no sense. Perhaps you are already on it, Daniel? > > I think the actual reason for the difference is that the methods that > are taking care to zero the pointer do so because they test the > pointer themselves. For instance in EndCompressorGzip, the test is > needed because perhaps no data was sent so the struct never got made. > It incidentally offers protection against a double call of that > function, but I don't think that was the intended reason. > > I don't have any big objection to zeroing the pointer in > EndCompressorZstd, but I think the claim that it's precisely > analogous to the other EndCompressor methods is faulty, > because it has no similar test.
Right, it has no similar test as the state in private_data is needed for both read and write whereas gzip for example only need it for write (deflate). Pushed as it improves code hygiene. -- Daniel Gustafsson
