Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-18 5:48 GMT+02:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:

> On 18 October 2016 at 04:19, Andres Freund <andres(at)anarazel(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>