Honestly I don't even like JS. Having said that I am not too crazy about PL-PGSQL either. I am willing to put up with either given that they are supported widely in default installs of postgres in AWS, Linux and MacOSX,
As I said before, I think posgres gives a unique and underutilized language platform. You can code in different languages, it has a good variety of built in types, and of course you get persistance and caching built in! Using DBLINK you might even be able to separate out your code from the bulk of your data in another database. Postgres all the way down!
It's fun to play around with. There is a lot of missing pieces though. A good IDE like thing would be good, version control would be nice, deeper namespacing (hierarchical schemas?), easier testing etc would go a long way.
Thanks for all the input guys!
On Fri, Dec 30, 2016 at 12:14 AM, Ivan Sergio Borgonovo <mail@xxxxxxxxxxxxxxx> wrote:
On 12/29/2016 10:35 AM, Pavel Stehule wrote:
2016-12-29 10:03 GMT+01:00 Tim Uckun <timuckun@xxxxxxxxx
<mailto:timuckun@xxxxxxxxx>>:
I think it's awesome that postgres allows you to code in different
languages like this. It really is a unique development environment
and one that is overlooked as a development platform. It would be
nice if more languages were delivered in the default package
especially lua, V8 and mruby.
It is about dependencies and maintenance. There are not too much people
who has good experience with C embedding Lua, V8 and others. Any people
who can do some work are welcome.
The living outside main package has disadvantages - only enthusiast
knows about it, but some advantages too - you are not fixed on
PostgreSQL development cycle, and development can be faster.
I'll add my 2 cents.
Postgresql and in general SQL are about integrity and coherency.
Checking coherency is much easier with strict data type.
PL/PGSQL gives you that, JS is far far away from that.
Postgresql is a very flexible database and you can stretch it to do "MEAN like"[1] stuff but that's going to increase your "impedance mismatch".
If you think there is some space for JS in your application stack that's nearer to the client rather than to the DB.
Or possibly you need to do "MEAN like" stuff but you don't want to install another "database".
As other said using stored procedures is a two edged sword.
It can decouple DB schema from the application or it can increase the coupling.
Choosing JS for performance in the stored procedure realm is going to encourage coupling and make scalability harder and it is going to become a mess when you'll need to refactor.
[1] https://en.wikipedia.org/wiki/MEAN_(software_bundle)
--
Ivan Sergio Borgonovo
http://www.webthatworks.it http://www.borgonovo.net
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
