I would hope Postgres core folk take no more than a nanosecond to reject the idea that they work on an IDE. Focus on reading and writing faster and faster ACID all the while.
> On Dec 29, 2016, at 5:32 PM, Tim Uckun <timuc...@gmail.com> wrote: > > 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 >> <m...@webthatworks.it> wrote: >> On 12/29/2016 10:35 AM, Pavel Stehule wrote: >> >>> 2016-12-29 10:03 GMT+01:00 Tim Uckun <timuc...@gmail.com >>> <mailto:timuc...@gmail.com>>: >>> >>> 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@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general >
