Re: RustgreSQL

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.

> 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)