Re: RustgreSQL

2017-01-09 1:21 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 1/8/17 5:56 PM, Greg Stark wrote:
>
>> On 8 January 2017 at 21:50, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>