On 10 January 2017 at 09:54, Joel Jacobson <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
