On Thu, May 8, 2014 at 12:19 AM, Craig Ringer cr...@2ndquadrant.com wrote:
In terms of ugliness, would you be happier using a pg_extern instead of
extern, where we:
#ifdef WIN32
#define pg_extern extern PGDLLIMPORT
#else
#define pg_extern extern
#endif
?
I personally would not be
On 2014-05-08 07:56:46 -0400, Robert Haas wrote:
On Thu, May 8, 2014 at 12:19 AM, Craig Ringer cr...@2ndquadrant.com wrote:
In terms of ugliness, would you be happier using a pg_extern instead of
extern, where we:
#ifdef WIN32
#define pg_extern extern PGDLLIMPORT
#else
#define
Hi all
As part of development on BDR the issue of GUC globals not being
PGDLLEXPORT'ed has been run into a few times.
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
Barring objections I'll post a patch to do this tomorrow.
--
Craig Ringer
Craig Ringer cr...@2ndquadrant.com writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally equivalent to is there a reason not to make every
static variable global?.
IOW, no, I don't accept this proposition. Every time we DLLEXPORT some
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally equivalent to is there a reason not to make every
static variable global?.
IOW, no, I don't
On 05/07/2014 09:45 PM, Andres Freund wrote:
I think what Craig actually tries to propose is to mark all GUCs
currently exported in headers PGDLLIMPORT. Currently it's easy to have
extensions that work on sane systems but not windows. If they're already
exposed in headers I don't think changes
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally equivalent to is there a reason not to make every
static
Tom Lane-2 wrote
Andres Freund lt;
andres@
gt; writes:
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
Craig Ringer lt;
craig@
gt; writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally equivalent to is there a reason not to make
On 2014-05-07 10:29:36 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-07 10:29:36 -0400, Tom Lane wrote:
To my mind, we PGDLLEXPORT some variable only after deciding that yeah,
we're okay with having third-party modules touching that. Craig's
proposal is to remove human judgement from that process.
It's
On Wed, May 7, 2014 at 11:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-07 10:29:36 -0400, Tom Lane wrote:
To my mind, we PGDLLEXPORT some variable only after deciding that yeah,
we're okay with having third-party modules touching that.
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
On 2014-05-07 12:21:55 -0400, Tom Lane wrote:
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.
On Wed, May 7, 2014 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
Robert Haas robertmh...@gmail.com writes:
On Wed, May 7, 2014 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On 2014-05-07 13:08:52 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 7, 2014 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Wed, May 7, 2014 at 1:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 7, 2014 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If Craig has a concrete argument why all GUCs should be accessible
to external modules, then let's see it (after
On 05/08/2014 12:21 AM, Tom Lane wrote:
If Craig has a concrete argument why all GUCs should be accessible
to external modules, then let's see it
Because they already are.
The only difference here is that that access works only on !windows.
I agree (strongly) that we should have a better
Craig Ringer cr...@2ndquadrant.com writes:
On 05/08/2014 12:21 AM, Tom Lane wrote:
If Craig has a concrete argument why all GUCs should be accessible
to external modules, then let's see it
As for just GUCs: I suggested GUCs because GUCs are what's been coming
up repeatedly as an actual
On 05/08/2014 10:53 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 05/08/2014 12:21 AM, Tom Lane wrote:
If Craig has a concrete argument why all GUCs should be accessible
to external modules, then let's see it
As for just GUCs: I suggested GUCs because GUCs are what's
20 matches
Mail list logo
