2017-01-09 1:21 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>: > On 1/8/17 5:56 PM, Greg Stark wrote: > >> 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. >> > > 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. >> >> 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 >> > > 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) > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
