2016-10-18 5:48 GMT+02:00 Craig Ringer <cr...@2ndquadrant.com>: > On 18 October 2016 at 04:19, Andres Freund <and...@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. >
Not all called functions has V1 interface. I understand so plpgsql_check is not usual extension and it is a exception, but there is lot of cross calls. I can use a technique used by Tom in last changes in python's extension, but I am not able do check in linux gcc. Regards Pavel > > -- > 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 >
