On 10 January 2017 at 09:54, Joel Jacobson <joel@trustly.com> wrote:
> One idea of an area that would be most useful from a user-perspective
> is probably all pg_catalog functions that are immutable.
> They should be able to be written without expertise of the PostgreSQL internals,
> since they only depend on the input parameters to produce the output.
Wait, what?
No, that doesn't follow at all.
Immutable functions can and do use functionality from all over the
server. They just don't depend on user-visible mutable _state_
elsewhere in the server.
As with all the rest, you'd need something that integrates well enough
with C that you can use C functions ... and macros. In which case
you're basically writing C.
That's why I mentioned upthread that C++ is probably the only
reasonably likely direction to go in, if we ever change, and probably
only a progressive change based on a restricted subset of C++ if we
start needing C++-only features, start having platform support issues,
etc. The common subset of C and C++ is a large portion of the C
language.
> And that also means is should be easier to write them in a different
> language than C,
> because they don't need access to any PostgreSQL internal data structures,
> or make use of existing C functions.
Not the case at all. You'd need a large adapter layer for pretty much
any language to handle interaction with Pg's data types, memory
management, etc.
We don't currently define a formal public API or a "safe" subset of
PostgreSQL's C interfaces. Anyone who wanted to make a serious attempt
at writing "safe" or "fenced" C extensions in another language that
supports restricted execution would need to start there. Whether they
want to use NaCL, .NET Core or Mono and C#, Java with SecurityManager,
or whatever.
That's what the existing PL/Perl does, it just has a _very_ small part
of PostgreSQL's interfaces exposed, so it's very limited in what it
can actually do.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services