ne 22. 8. 2021 v 14:08 odesÃlatel Julien Rouhaud <rjuju...@gmail.com> napsal:
> On Sun, Aug 22, 2021 at 08:51:26PM +0900, Michael Paquier wrote: > > On Sun, Aug 22, 2021 at 04:10:33PM +0800, Julien Rouhaud wrote: > > > This topic has been raised multiple time over the years, and I don't > see any > > > objection to add such an annotation at least for all GUC variables > (either the > > > direct variables or the indirect variables set during the hook > execution), so > > > PFA a patch that takes care of all the GUC. > > > > > > I don't now if that's still an option at that point, but backporting > to at > > > least pg14 if that patch is accepted would be quite helpful. > > > > These are usually just applied on HEAD > > Yeah but 14 isn't released yet, and this is a really low risk change. > > > , and on a parameter-basis based > > on requests from extension authors. If you wish to make your > > extensions able to work on Windows, that's a good idea, but I would > > recommend to limit this exercise to what's really necessary for your > > purpose. > > I disagree. For random global variables I agree that we shouldn't mark > them > all blindly, but for GUCs it's pretty clear that they're intended to be > accessible from any caller, including extensions. Why treating Windows as > a > second-class citizen, especially when any change can only be used a year > after > someone complained? > I had few problems with access with these variables too when I worked on orafce. Is true, so it increases differences between Windows and Unix, and fixing these issues is not fun work. On the other hand, maybe direct access to these variables from extensions is an antipattern, and we should use a direct function call API and functions current_setting and set_config. The overhead is usually not too big.
