On 2014-05-08 07:56:46 -0400, Robert Haas wrote:
> On Thu, May 8, 2014 at 12:19 AM, Craig Ringer 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 ex
On Thu, May 8, 2014 at 12:19 AM, Craig Ringer 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 happier with that.
On 05/08/2014 10:53 AM, Tom Lane wrote:
> Craig Ringer 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
>
Craig Ringer 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 practical issue.
Me
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 def
On Wed, May 7, 2014 at 1:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 7, 2014 at 12:21 PM, Tom Lane 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 ar
On 2014-05-07 13:08:52 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, May 7, 2014 at 12:21 PM, Tom Lane 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 a
Robert Haas writes:
> On Wed, May 7, 2014 at 12:21 PM, Tom Lane 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 guc.c).
> I think there's actually
On Wed, May 7, 2014 at 12:21 PM, Tom Lane wrote:
> Robert Haas 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
On 2014-05-07 12:21:55 -0400, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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
P
On Wed, May 7, 2014 at 11:19 AM, Tom Lane wrote:
> Andres Freund 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 hu
Andres Freund 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 just levelling
On 2014-05-07 10:29:36 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
> >> Craig Ringer writes:
> >>> Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
> >>> concerns?
>
> >> That seems morally equivalent to "is there a reaso
Tom Lane-2 wrote
> Andres Freund <
> andres@
> > writes:
>> On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
>>> Craig Ringer <
> craig@
> > writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
>
>>> That seems morally equivalent to "is there a reason
Andres Freund writes:
> On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
>> Craig Ringer 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?".
> I think
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 chan
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
> Craig Ringer 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 pro
Craig Ringer 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
variable, we lose the
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 ht
20 matches
Mail list logo