>>>>> "Stefan" == Stefan Wolf <sw@zpmt.de> writes:
Stefan> I´ve written some PostgreSQL C-Extensions (for the first
Stefan> time...) and they work as expected.
Stefan> But now I want to call other functions from inside the
Stefan> C-Extensions (but not via SPI_execute), for example
Stefan> "regexp_match()" or from other extensions like PostGIS
Stefan> "ST_POINT" etc...
Stefan> I think "fmgr" is the key - but I didn't find any examples.
There are a number of levels of difficulty here depending on which
specific functions you need to call and whether you need to handle
NULLs.
The simplest case is using DirectFunctionCall[N][Coll] to call a builtin
(internal-language) function. This _only_ works for functions that don't
require access to an flinfo; many functions either need the flinfo to
get parameter type info or to use fn_extra as a per-callsite cache.
(Also there's no guarantee that a function that works without flinfo now
will continue to do so in future versions.) One restriction of this
method is that neither parameters nor results may be NULL.
The next step up from that is getting a function's Oid and using
OidFunctionCall[N][Coll]. This can call functions in any language,
including dynamic-loaded ones, but it can't handle polymorphic
functions. (Overloaded functions are fine, since each overload has its
own Oid.) This is still fairly simple but is inefficient: it constructs
and populates the flinfo, calls it once, then abandons it (it's not even
freed, it's up to the calling memory context to do that). If you're
going to be invoking a function repeatedly, it's worth avoiding this
one. This still has the restriction of no NULLs either in or out.
The next step from that is calling fmgr_info and FunctionCall[N][Coll]
separately (which is just breaking down OidFunctionCall into its parts);
this allows you to re-use the flinfo for multiple calls. Still no NULLs
allowed, but it's possible to use polymorphic functions if you try hard
enough (it's not documented, but it requires consing up a faked
expression tree and using fmgr_info_set_expr).
Finally, if none of the above apply, you're at the level where you
should seriously consider using SPI regardless; but if you don't want to
do that, you can use fmgr_info, InitFunctionCallInfoData and
FunctionCallInvoke.
--
Andrew (irc:RhodiumToad)