Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
От | Craig Ringer |
---|---|
Тема | Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 |
Дата | |
Msg-id | CAMsr+YGk5bYwCF7vhu5H5sy_ATk-O7ZkCsx=o9njCoiCKUGynA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 |
Список | pgsql-hackers |
On 18 October 2016 at 04:19, Andres Freund <andres@anarazel.de> wrote: > On 2016-10-17 16:16:37 -0400, Robert Haas wrote: >> I wouldn't think that cross-file references would be especially >> common. Functions that take PG_FUNCTION_ARGS and return Datum aren't >> a lot of fun to call from C. But maybe I'm wrong. > > There's a fair number of DirectFunctionCall$Ns over the backend. It's only an issue if one contrib calls another contrib (or the core backend code calls into a contrib, but that's unlikely) via DirectFunctionCall . If changed to use regular OidFunctionCall they'll go via the catalogs and be fine, albeit at a small performance penalty. In many cases that can be eliminated by caching the fmgr info and using FunctionCall directly, but it requires taking a lock on the function or registering for invalidations so it's often not worth it. Personally I think it'd be cleaner to avoid one contrib referencing another's headers directly and we have the fmgr infrastructure to make it unnecessary. But I don't really think it's a problem that especially needs solving either. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: