Re: Mark all GUC variable as PGDLLIMPORT
От | Julien Rouhaud |
---|---|
Тема | Re: Mark all GUC variable as PGDLLIMPORT |
Дата | |
Msg-id | CAOBaU_Zfe9BU84gtxFp70Y_w-L94XC+9ex9OjS-9G-pd4iR2=g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Mark all GUC variable as PGDLLIMPORT (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Mark all GUC variable as PGDLLIMPORT
|
Список | pgsql-hackers |
On Mon, Aug 23, 2021 at 10:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > On Mon, Aug 23, 2021 at 10:15:04AM -0400, Tom Lane wrote: > >> By that argument, *every* globally-visible variable should be marked > >> PGDLLIMPORT. But the mere fact that two backend .c files need to access > > > No, Julien says 99% need only the GUCs, so that is not the argument I am > > making. > > That's a claim unbacked by any evidence that I've seen. More to > the point, we already have a mechanism that extensions can/should > use to read and write GUC settings, and it's not direct access. I clearly didn't try all single extension available out there. It's excessively annoying to compile extensions on Windows, and also I don't have a lot of dependencies installed so there are some that I wasn't able to test since I'm lacking some other lib and given my absolute lack of knowledge of that platform I didn't spent time trying to install those. I think I tested a dozen of "small" extensions (I'm assuming that the big one like postgis would require too much effort to build, and they probably already take care of Windows compatibility), and I only faced this problem. That's maybe not a representative set, but I also doubt that I was unlucky enough to find the few only exceptions.
В списке pgsql-hackers по дате отправления: