On Wed, May 7, 2014 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
I think there's actually a very good reason to think that GUCs are
good candidates for this treatment, which is that, by definition, the
GUC is a public interface: you can change it with a SET command. It's
certainly easier to imagine an extension wanting access to
update_process_title than, say, criticalRelcachesBuilt.
But maybe you're right and we should revisit the idea of exposing
everything. A quick grep through src/include suggests that GUCs are a
big percentage of what's not marked PGDLLEXPORT anyway, and the other
stuff that's in there is stuff like PgStartTime and PostmasterPid
which hardly seem like silly things to expose.
I certainly think we should err on the side of exposing stuff that
people think might be useful rather than pretending that we can stop
them from using symbols by refusing to PGDLLEXPORT them. We can't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company