On 8 January 2017 at 21:50, Jim Nasby <jim.na...@bluetreble.com> wrote: > Somewhat related to that... it would be useful if Postgres had "fenced" > functions; functions that ran in a separate process and only talked to a > backend via a well defined API (such as libpq). There's two major advantages > that would give us:
The problem with this is that any of the "interesting" extensions need to use the server API. That is, they need to be able to do things like throw errors, expand toast data, etc. IMHO just about anything you could do in an external process would be something you could much more easily and conveniently do in the client. And it would be more flexible and scalable as well as it's a lot easier to add more clients than it is to scale up the database. That said, there were several pl language implementations that worked this way. IIRC one of the Java pl languages ran in a separate Java process. I think the solution to the problem you're describing is the project formerly known as NaCl https://en.wikipedia.org/wiki/Google_Native_Client -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
