On 01/13/2014 02:04 AM, Tom Lane wrote:
> Craig Ringer <craig@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
