On 28/09/10 11:09, Itagaki Takahiro wrote:
> On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas <robertmh...@gmail.com> wrote:
>>> Since we have PGDLLEXPORT in 9.0, we can mark some of exported
>>> functions with it in tutorial codes and maybe contrib modules.
>>
>> If that (a) works and (b) reduces user confusion, +1 from me. We've
>> gotten this question a few times lately.
>
> If we do so, many PGDLLEXPORT will be added:
> * 17 in src/tutorial
> * 507 in contrib
> for each exported PGFunction, _PG_init, and _PG_fini.
>
> Any objections? Am I missing something?
For what it's worth, these macros are useful for more than Windows.
They can be used with gcc's visibility features to reduce the size of
the symbol table and therefore speed linking and backend startup. This
isn't as important in a C-only program as it is in a C++ program (which
has huge collections of private symbols) but it still won't hurt. If
building with gcc4 on a non-Windows platform, the PGDLLEXPORT macro can
be defined as:
#define PGDLLEXPORT __attribute__ ((visibility("default")))
and gcc can be invoked with -fvisibility=hidden to make symbols not
explicitly exported hidden by default. A handy advantage of this is that
it'll cause code that would compile and run correctly on *nix and fail
on Windows to also fail on *nix, making it easier for *nix based
developers (ie sane, happy people) to catch issues that'll break Windows.
Such macros also serve as documentation markers indicating public API.
They're ugly, but they're not purely Windows ugly.
--
Craig Ringer
Tech-related writing: http://soapyfrogs.blogspot.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
