On Wed, Jun 06, 2018 at 09:58:34AM +0530, Amit Kapila wrote: > On Wed, Jun 6, 2018 at 8:28 AM, Michael Paquier <mich...@paquier.xyz> wrote: >> Ouch. Including directly c.h as you do here is against project policy >> code. See recent commit a72f0365 for example. pgwin32_open() is >> visibly able to handle frontend code if I read this code correctly, so >> could we just remove the "#ifndef FRONTEND" restriction? > > I think we need to explore a bit, if we want to remove that, for example > some of the frontend modules (like pg_receivewal, pg_recvlogical) call two > argument open which would require change.
Yeah, sure. I am not saying that this is straight-forward, but it may be worth the switch in the long term. What I am sure about is that the proposed patch is simple, but that does not look like a correct approach to me as other tools may benefit from it. >> It could be >> risky for existing callers of open() for tool maintainers, or on the >> contrary people could welcome a wrapper of open() which is >> concurrent-safe in their own tools. > > I am not sure if we can safely assume that because using these functions > would allow users to concurrently delete the files, but may be it is okay > for all the FRONTEND modules. One another alternative could be that we > define open as pgwin32_open (for WIN32) wherever we need it. Which is what basically happens on any *nix platform, are you foreseeing anything bad here? Windows has the characteristic in being particular in everything, which is its main characteristic, so I may be missing something of course. -- Michael
signature.asc
Description: PGP signature
