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
19 matches
Mail list logo
