3 ms·
Well, you can write stored procedures in JS/Perl/Python for Postgres, but not necessarily for other databases. And if you do it's probably not portable. And the
by vosper 9y ago
Well, you can write stored procedures in JS/Perl/Python for Postgres, but not necessarily for other databases. And if you do it's probably not portable. And the fact that this capability exists I think is some evidence that sometimes you can't do enough with SQL to do everything you need in SQL.
Anyway, I was talking in generalities, not about Postgres specifically. I would argue that if you're going to use Python to write stored procedures, why not just write a traditional Python script/app with SQLAlchemy? That SQLAlchemy has an ORM capability doesn't mean it needs to be used that way, as it's creator takes pains to point out. And this is a much more common pattern for using Python with a database, which is to my original point that its easier for most people to do.
- ruslan_talpa 9y agopython for stored procedures: bring code to the data, not data to the code, i.e. it's much much faster because there is no overhead for shuffling data over the network, a few serializing steps and everything in between. It's much more probable that you will switch your language/framework then changing the database. This fear of "database lock-in" is unreasonable and the source of many not so good patterns ( as in ORM :) ). The only reasonable rationale for fear of lock-in is Oracle :) but you again, it's unreasonable, and you even semi-automated processes for migrating https://aws.amazon.com/dms/ https://aws.amazon.com/dms/