
V8 Engine in PostgreSQL - craigkerstiens
http://code.google.com/p/plv8js/wiki/PLV8
======
pfraze
Well that's even more interesting than v8 in PHP. Ignoring the obvious
question of performance, are there any use cases that are unique to this
approach? I can see procedurally generating data or writing business logic in
the db, but I'm not sure whether those ideas are that limited by the current
alternatives. Perhaps in situations where it's difficult to put a layer
between the DB and the consumers of the DB.

~~~
y0ghur7_xxx
Most apps we write at work are boring data entry apps.

You have a form, you enter data, the data is somehow aggregated and presented
to you in some other form or the data is sent off to some other service that
then processes the data in some other way.

Removing a layer between the JS frontend and the DB just simplifies the whole
stack: if postgres can do something like

    
    
       (select * from employees).to_json
    

and send it to the JS frontend that's already half of the app. The other half
would be

    
    
       var record = {"empId": 2, "empName": "Franz"}
       insert into employees (emp_id, emp_name) values (record.empId, record.empName);
    
    

No java, .NET, ruby or python required. Plus it makes the sysOps happy: they
have less stuff to handle.

~~~
zbuc
What was the handwaving "send it to the JS frontend"?

Are you suggesting you allow the client-side JS app to call directly against
the Postgres DB or is there another approach you had in mind?

~~~
einhverfr
I don't see how that differs from allowing a thick client written in wxPerl
from directly connecting to the database. It seems quite useful in many cases.

One thing to keep in mind about PostgreSQL is you can do a lot of traditional
middleware tasks (including message queues) in the database back-end with
transactional control. These can even be hooked into other applications
Remember, you can put a lot of what would otherwise go in a middleware layer
in the database itself, especially with features in PostgreSQL like
LISTEN/NOTIFY.

There are some limitations of this approach, but in general, I have found it
ideal, but it requires thinking about your database differently. Instead of a
data store on the bottom of the stack, you have an intelligent data storage
and queuing system in the center of your environment.

~~~
cbsmith
One of the interesting changes in our reality, is the case for increasing
scalability by having a middleware layer that does all the work has become
quite weak. It's much cleaner to partition your systems and work that way.

~~~
einhverfr
I don't think it's just that the performance case for middleware has become
weak. It's also that traditionally you pay per connection some sort of license
fee. So if you are running Oracle or SQL Server, and you want to add
additional clients that, say, do additional process on notification, that
means additional license fees. This isn't a problem on PostgreSQL.

It means there are choices between the traditional ones of putting everything
in the database or in the middleware.

