From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PGDLLEXPORTing all GUCs? |
Date: | 2014-05-07 16:42:03 |
Message-ID: | 20140507164203.GG13397@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-05-07 12:21:55 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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.
GUCs in general are user configurable things. So it's not particularly
unreasonable to assume that a significant fraction of them are of
interest to extensions. And it's not like exporting them gives way to
many additional dangers - they already can be overwritten.
In fact, I am pretty sure that nearly all of these cases are about
*reading* the underlying variable not writing them. It's pretty darn
less convenient and far slower to get the config variable as text and
then convert it to the underlying type.
> (after which we'd better debate exposing the few that are in fact
> static in guc.c).
I plan to do that for most of them - completely independently of this
topic. I think 'export'ing a variable in several files is a horrible idea.
> Or if you want
> to hang your hat on the platform-leveling argument, then we should be
> re-debating exporting *all* global variables.
Yes. I am wondering whether that's not the most sensible course. It's a
pita, but essentially we'd have to do a global s/export/pg_export/ in
the headers.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-05-07 16:43:19 | Re: [v9.5] Custom Plan API |
Previous Message | Heikki Linnakangas | 2014-05-07 16:38:42 | Re: Schizophrenic coding in gin_extract_jsonb(_hash) |