Re: PGDLLEXPORTing all GUCs? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PGDLLEXPORTing all GUCs?
Date
Msg-id 29777.1399479715@sss.pgh.pa.us
Whole thread Raw
In response to Re: PGDLLEXPORTing all GUCs?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: PGDLLEXPORTing all GUCs?  (Andres Freund <andres@2ndquadrant.com>)
Re: PGDLLEXPORTing all GUCs?  (Robert Haas <robertmhaas@gmail.com>)
Re: PGDLLEXPORTing all GUCs?  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I don't accept this argument.  In EnterpriseDB's Advanced Server fork
> of PostgreSQL, we've marked a bunch of extra things PGDLLEXPORT
> precisely because we have external modules that need access to them.

Well, that's an argument for marking every darn global variable as
PGDLLEXPORT.  But it's *not* an argument for marking GUCs in particular
that way.  In particular, you are conveniently ignoring the point that
GUCs are much more likely to be global as an artifact of the way guc.c
is modularized than because we actually think they should be globally
accessible.

If Craig has a concrete argument why all GUCs should be accessible
to external modules, then let's see it (after which we'd better debate
exposing the few that are in fact static in guc.c).  Or if you want
to hang your hat on the platform-leveling argument, then we should be
re-debating exporting *all* global variables.  But as far as the actually
proposed patch goes, all I'm hearing is very confused thinking.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PGDLLEXPORTing all GUCs?
Next
From: Stephen Frost
Date:
Subject: Re: [v9.5] Custom Plan API