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.
There's plenty of interesting things you can do in python or R, even without that ability.
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.
Well, then you're suffering from serious network latency, and you're forced into worrying about endian issues and what-not. Those problems don't exist when you're running on the same server. There's also things that might make sense on a local-only protocol but would make no sense with an external one. My guess is that you'd ultimately want a protocol that's something "in between" SPI and libpq.
The running unsafe PL in own managed processes is good idea - Years, I have a one diploma theme "better management of unsafe PL in Postgres" - but still without any interest from students :(. I had two possibilities to see catastrophic errors related to wrong usage of PLPerlu. If we can locks interpret/environment in some safe sandbox, then it should be great.
Regards
Pavel
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.
Possibly; depends on if it would allow running things like R or python. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)