Re: Create function prototype as part of PG_FUNCTION_INFO_V1
От | Tom Lane |
---|---|
Тема | Re: Create function prototype as part of PG_FUNCTION_INFO_V1 |
Дата | |
Msg-id | 12252.1389764501@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Create function prototype as part of PG_FUNCTION_INFO_V1 (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Create function prototype as part of
PG_FUNCTION_INFO_V1
Re: Create function prototype as part of PG_FUNCTION_INFO_V1 |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > This idea has appeared at least twice now, in > http://www.postgresql.org/message-id/1386301050.2743.17.camel@vanquo.pezone.net and http://www.postgresql.org/message-id/52D25AA2.50108@2ndquadrant.com. Even if it doesn't help with Windows issues, as discussedin the second thread, it still seems like a win for reducing boilerplate and accidental compiler warnings. So hereis a patch for consideration. Meh. I don't think that extension authors are really going to appreciate changing from "thou shalt declare all thy functions" to "thou shalt declare none of them". If the code were such that it wouldn't matter whether a manual declaration were provided too, then that wouldn't be a big deal --- but you seem to be ignoring the discussion in the one thread cited above about PGDLLEXPORT. Also, surely it is 100% bogus for fmgr.h to be declaring functions not actually provided by fmgr.c. That will create about as many failure modes as it removes, not to mention being conceptually wrong. The latter point might possibly be worked around by putting the externs for _PG_init and _PG_fini into the PG_MODULE_MAGIC macro, though I'm not sure how well that works for multi-source-file extensions; the init functions might be in some other file than the PG_MODULE_MAGIC call. regards, tom lane
В списке pgsql-hackers по дате отправления: