On 01/12/2014 04:54 PM, Craig Ringer wrote:
> On 01/12/2014 12:00 AM, Tom Lane wrote:
>> So if it's really necessary to change anything here, I'd rather see us
>> take the approach of hiding it in PG_FUNCTION_INFO_V1.  What happens
>> if we do that and there's also a manually-written prototype?
> That's certainly
> one option, anyway, and one that'll solve the immediate issue with
> extensions, and would be the most practical short term solution if it works.

... which it kind-of does.

Turned out to be trivial to test. If the prototype with PGDLLEXPORT
appears *first*, then all is well. If the prototype with PGDLLEXPORT
appears AFTER a user-provided prototype it fails with:

1>DemoExtension.c(16): error C2375: 'add_one' : redefinition; different
1>          DemoExtension.c(14) : see declaration of 'add_one'

Two copies of the prototype, both with PGDLLEXPORT, work fine.

So really the question is: Do we care? The current usage of extensions
built outside the Pg tree on Windows is likely to be nearly zero, and is
already fiddly. I'm not too fussed if we make people fix up their

I think we can just emit a prototype for the function from
PG_FUNCTION_INFO_V1 . The only things it's going to break is the odd bit
of weirdly-built, not really supported extensions on Windows.

Are there any platforms that object to prototype redefinition? If not,
we can just emit a prototype on all platforms, not just Windows.

 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:

Reply via email to