From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PGDLLEXPORTing all GUCs? |
Date: | 2014-05-08 02:53:45 |
Message-ID: | 17254.1399517625@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Craig Ringer <craig(at)2ndquadrant(dot)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 practical issue.
Meh. A quick look through the commit logs says that GUC variables are not
more than 50% of what we've had to PGDLLIMPORT'ify in the past year or
two. Maybe that's different from 2ndQuadrant's internal experience,
but then you've not showed us the use-case driving your changes.
> I'd be quite happy to
> PGDLLEXPORT all extern vars, but I was confident that'd be rejected for
> aesthetic reasons, and thought that exporting all GUCs would be a
> reasonable compromise.
From the aesthetic standpoint, what I'd like is to not have to blanket
our source code with Windows-isms. But I guess I can't have that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Shigeru Hanada | 2014-05-08 03:02:41 | Re: [v9.5] Custom Plan API |
Previous Message | Tom Lane | 2014-05-08 02:44:57 | Re: Wanted: jsonb on-disk representation documentation |