Re: Mark all GUC variable as PGDLLIMPORT - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id CA+Tgmoa5PG4YS-MnaLJ8X2aBW5nt394gGmcPDvn30o4QouK6Tw@mail.gmail.com
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: Mark all GUC variable as PGDLLIMPORT
List pgsql-hackers
On Tue, Aug 24, 2021 at 5:06 PM Chapman Flack <chap@anastigmatix.net> wrote:
> The thing is, I think I have somewhere a list of all the threads on this
> topic that I've read through since the first time I had to come with my own
> hat in hand asking for a PGDLLIMPORT on something, years ago now, and
> I don't think I have ever seen one where it was as uncontroversial
> as you suggest.

It does tend to be controversial, but I think that's basically only
because Tom Lane has reservations about it. I think if Tom dropped his
opposition to this, nobody else would really care. And I think that
would be a good thing for the project.

> In each iteration, I think I've also seen a countervailing view expressed
> in favor of looking into whether globals visibility could be further
> /reduced/.

But, like I say, that's only a view that gets advanced as a reason not
to mark things PGDLLIMPORT. Nobody ever wants that thing for its own
sake. I think it's a complete red herring.

If and when somebody wants to make a serious proposal to do something
like that, it can be considered on its own merits. But between now and
then, refusing to make things work on Windows as they do on Linux does
not benefit anyone. A ton of work has been made into making PostgreSQL
portable over the years, and abandoning it in just this one case is
unreasonable.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: Failure of subscription tests with topminnow
Next
From: Robert Haas
Date:
Subject: Re: Postgres perl module namespace