| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PGDLLEXPORTing all GUCs? |
| Date: | 2014-05-07 13:45:00 |
| Message-ID: | 20140507134500.GC13397@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
> Craig Ringer <craig(at)2ndquadrant(dot)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
> variable, we lose the freedom to redefine it later. So DLLEXPORT'ing GUCs
> should be on a case by case basis, just as for any other variable. In
> some cases it might be smarter to export a wrapper function.
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 get any harder just because thy
also can get used on windows...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-05-07 13:50:12 | Re: Wanted: jsonb on-disk representation documentation |
| Previous Message | Tom Lane | 2014-05-07 13:44:36 | Re: Wanted: jsonb on-disk representation documentation |