Re: [rfc] new CREATE FUNCTION (and more)

Nathan Myers <ncm@zembu.com> writes:
> Why declare a function instead of a static struct?

Well, two reasons.  One is that a function provides wiggle room if we
later decide that the library needs to do some computation before
handing back the function info struct.  For example, Philip suggested
that the info function might be just a stub that causes an additional
library to be loaded.  I'm not sure we'll ever really *need* such
flexibility in the future, but when it costs hardly anything to leave
the option open, why not?

The second reason is that if it's a function call, we only have one
primitive lookup operation that we expect the dynamic loader to be able
to support: find a function in a shlib by name.  We have that already in
order to be able to call the real function.  If it's a global variable,
then we need a second primitive lookup operation: find a global variable
in a shlib by name.  Given the way that dynamic-link shared libraries
work, this is *not* necessarily the same as the first operation (code
and data are handled much differently in a shared library!) and might
not even be available on all platforms.  At the very least it'd imply a
round of per-platform development and portability testing that I doubt
we can afford if we want to shoehorn this feature into the 7.1 schedule.

In short, using a variable looks like more work for less functionality,
and so the choice seems pretty clear-cut to me: use a function.

> Users are allowed to have functions that start 
> with "pg" already, and that's quite a reasonable prefix for 
> functions meant to be called by Postgres.  Therefore, I suggest 
> a prefix "_pg" instead of "pg".  Thus,

>   const struct _pg_user_function _pg_user_function_foo = { 2, };

The exact details of the name prefix need to be settled regardless
of whether the name is attached to a variable or a function.  I was
thinking of pg_finfo_foo for a function named foo.  We want to keep
the prefix reasonably short, so as to reduce the risk of duplicate-
symbol conflicts if the platform's linker truncates names to some
fixed length (I'm sure there are still some that do :-().  Using
a leading underscore (_pg_info_foo) might help but I worry about
creating conflicts with system names if we do that.
        regards, tom lane