Hi, On Sat, Feb 12, 2022 at 07:59:56PM -0800, Andres Freund wrote: > > On 2021-08-23 14:53:34 +0800, Julien Rouhaud wrote: > > So since the non currently explicitly exported GUC global variables > > shouldn't > > be accessible by third-party code, I'm attaching a POC patch that does the > > opposite of v1: enforce that restriction using a new pg_attribute_hidden() > > macro, defined with GCC only, to start discussing that topic. > > This fails on cfbot: https://cirrus-ci.com/task/6424663592009728?logs=build#L1 > > I'm not feeling a lot of enthusiasm for the change.
Yes, which is also why I'm not planning on spending more effort on that (or the opposite) unless I get some sort of feedback, so thanks a lot for the answer here. Note that if everyone is happy with the status quo please say so. I will happily mark the CF entry rejected and stop all efforts to try packaging extensions on Windows. It will save me a lot of efforts that 99% of users don't care about. If not maybe we could improve the situation, and also learn for the max_backend thread. Maybe we could have an actually usable GUC API to retrieve values in their native format rather than C string for instance, that we could make sure also works for cases like max_backend? > But if we were to do this, > we'd have to have infrastructure to detect missing hidden declarations, > otherwise it's inevitable that they don't get added. Agreed. For now I'm using a simple loop around egrep "^\s+&[A-Za-z_]+,$" src/backend/utils/misc/guc.c | egrep -o "[A-Za-z_]+" to get all the underlying symbols, and grep that again (actually using ag, which makes it 3x faster) to detect the lack of wanted annotation. Were you thinking of some script like that, maybe to run before a release, or something more evolved? > I kind of like the idea of hiding postgres symbols for other reasons than > win<->everything else parity. Namely that not exporting symbols can allow the > compiler to optimize more... Yeah I saw that in nearby threads and I entirely agree.
