On 01/13/2014 02:04 AM, Tom Lane wrote: > Craig Ringer <cr...@2ndquadrant.com> writes: > >> I think we can just emit a prototype for the function from >> PG_FUNCTION_INFO_V1. > > Doesn't sound like it.
On second thought, agreed. The externs tending to appear in headers kills that. In that case - after the rush for the CF close, expect a patch from me against post-9.4 that adds PGDLLEXPORT to the documentation examples, and another that adds them for contribs (to help people using them as examples). Nothing else needed, and it doesn't have to affect the *nix build process or server/ code in any way. I'll also add a note in the docs explaining what's wrong if you get an error about an obviously-present function being missing in your extension on Windows when it works on other platforms. > And I continue to maintain that it's not acceptable for the Windows port > to require this anyway. If any other platform came to us and said "hey > guys, you need to plaster this non-ANSI-C decoration on every exported > function", what response do you think they'd get? > > One last point is that "automatically export every external symbol" is > exactly what happens for these modules on Unix-ish platforms. If it > doesn't work the same way on Windows, we're just opening ourselves up to > subtle portability issues. The portability issues are easily dealt with by using gcc's symbol visibility features on *nix, which will produce slightly smaller binaries with faster linkage too. I'll demo that once I've got the current work off my plate. Platforms w/o gcc visibility don't need to care, nothing changes, they just don't get the benefits. Everyone develops on platforms that have gcc and visibility features so they'll spot any issues introduced. As described earlier, doing this helps differentiate "internal stuff" from "public API" if we choose to, as well. If we don't want to attempt to treat anything as "internal, non-public-use, non-stable API", then there's no point using visibility - everything not "static" is public API and should be exported to the world. That's how things are now. In that case I'd stick with just improving the docs to cover PGDLLEXPORT, and maybe the contribs. I do think we should think about actually hiding private internal API post-9.4, though. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
