Robert Haas <robertmh...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
