5 ms·

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

by pfraze 15y ago

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.

deleted 15y ago
[deleted]
craigkerstiens 15y ago
Performance is the really big one. I'm sure other use cases exist, but the performance difference in this case can be pretty massive. This presentation actually highlights some of the improvements in performance you'd get with it: http://pgeu-plv8.heroku.com http://pgeu-plv8.heroku.com
zalew 15y ago
Just another language to use instead of standard pl/pgsql. You already could use other languages - tcl, perl, python, or java, ruby, php and basically any one as long as you provide the handler and lang support is configured. I don't see why one would code DB procedures in JS though. Are there really many cases where a dba/designer's best known and favorite lang is JS? I doubt that.
- willvarfar 15y ago
  http://williamedwardscoder.tumblr.com/post/18065079081/cogs-bad#comment-445990171 http://williamedwardscoder.tumblr.com/post/18065079081/cogs-... "The controversy over Node is that it implies developers from the client are piercing into the server. A domain typically full of people that came up from the OS layer. Those people are asking does it really make sense to write servers in a historically client language? (One that as you mention is inherently far slower than historical server languages). People who only know or love that client language have been given a whole new freedom and ability - surely their answer is yes. Why wouldn't it be?" Very well put. And now they can put logic in the DB too. Bravo!
  - swasheck 15y ago
    Not sure why you're being downvoted. Though as one of those "data guys" I have actually received my own fair share of the reverse criticism. How could I, as a data monkey, be able to write anything close to clean, sensible code?
- mhurron 15y ago
  What about a DBA who used to write client side code? What about a developer who is putting proof-of-concept stuff in a dev environment? As you said, this just adds JS as yet another language to write stored procedures for PostgreSQL. There's no real need to disparage choice.
- einhverfr 15y ago
  I would think with stored procedures in Javascript and JSON as a native type you could mix and match SQL and NoSQL approaches to your heart's content!
y0ghur7_xxx 15y ago
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.
- route66 15y ago
  If you wait for 9.2 you can say SELECT query_to_json('select x as b, x * 2 as c from generate_series(1,3) x',false); http://people.planetpostgresql.org/andrew/index.php?/archives/244-Under-the-wire.html http://people.planetpostgresql.org/andrew/index.php?/archive... I can't find the link now, but the reverse (insert, update from json) I remember also to be possible.
- ibejoeb 15y ago
  Native JSON in 9.2: http://arstechnica.com/business/news/2012/01/native-json-features-submitted-for-postgresql-92.ars http://arstechnica.com/business/news/2012/01/native-json-fea...
- zbuc 15y ago
  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 15y ago
    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.
mikehuffman 15y ago
One obvious idea that I can think of is returning sanitized jsonp directly from the database to the controller. The database will nearly always be faster at formatting data in different ways, than the controller.

by pfraze 15y ago

deleted 15y ago

[deleted]

craigkerstiens 15y ago

Performance is the really big one. I'm sure other use cases exist, but the performance difference in this case can be pretty massive. This presentation actually highlights some of the improvements in performance you'd get with it: http://pgeu-plv8.heroku.com http://pgeu-plv8.heroku.com

zalew 15y ago

Just another language to use instead of standard pl/pgsql. You already could use other languages - tcl, perl, python, or java, ruby, php and basically any one as long as you provide the handler and lang support is configured. I don't see why one would code DB procedures in JS though. Are there really many cases where a dba/designer's best known and favorite lang is JS? I doubt that.

willvarfar 15y ago
http://williamedwardscoder.tumblr.com/post/18065079081/cogs-bad#comment-445990171 http://williamedwardscoder.tumblr.com/post/18065079081/cogs-... "The controversy over Node is that it implies developers from the client are piercing into the server. A domain typically full of people that came up from the OS layer. Those people are asking does it really make sense to write servers in a historically client language? (One that as you mention is inherently far slower than historical server languages). People who only know or love that client language have been given a whole new freedom and ability - surely their answer is yes. Why wouldn't it be?" Very well put. And now they can put logic in the DB too. Bravo!
- swasheck 15y ago
  Not sure why you're being downvoted. Though as one of those "data guys" I have actually received my own fair share of the reverse criticism. How could I, as a data monkey, be able to write anything close to clean, sensible code?
mhurron 15y ago
What about a DBA who used to write client side code? What about a developer who is putting proof-of-concept stuff in a dev environment? As you said, this just adds JS as yet another language to write stored procedures for PostgreSQL. There's no real need to disparage choice.
einhverfr 15y ago
I would think with stored procedures in Javascript and JSON as a native type you could mix and match SQL and NoSQL approaches to your heart's content!

y0ghur7_xxx 15y ago

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.

route66 15y ago
If you wait for 9.2 you can say SELECT query_to_json('select x as b, x * 2 as c from generate_series(1,3) x',false); http://people.planetpostgresql.org/andrew/index.php?/archives/244-Under-the-wire.html http://people.planetpostgresql.org/andrew/index.php?/archive... I can't find the link now, but the reverse (insert, update from json) I remember also to be possible.
ibejoeb 15y ago
Native JSON in 9.2: http://arstechnica.com/business/news/2012/01/native-json-features-submitted-for-postgresql-92.ars http://arstechnica.com/business/news/2012/01/native-json-fea...
zbuc 15y ago
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 15y ago
  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.

mikehuffman 15y ago

One obvious idea that I can think of is returning sanitized jsonp directly from the database to the controller. The database will nearly always be faster at formatting data in different ways, than the controller.