Hacker News Reader

Comment by dathinab | Hacker News Reader

Yes, but the constrains sql has wrt. how you represent certain datatypes can lead to problems. Sure in postgres you can fix that by a variety of compound types, and fully new types implemented as pg extension, which can scare people of.

Still there are a tone of applications for which just the basic types are good enough and the server is just a thin wrapper.

In the end the main requirement for efficiency using it is you skill with not basic SQL/plpgSQL (stored procedure, trigger functions, views and knowledge about the effects of the used isolation level). All well documented in postgres.

View on HN

> In the end the main requirement for efficiency using it is you skill with not basic SQL/plpgSQL

Another way I've heard this phrased is "It's much easier to hire JS devs than PL/pgSQL devs."

There's a postgres extension called plv8 that essentially allows one to write database functions in JavaScript, instead of plpgsql.

Oh, absolutely. Same with Python, Tcl, Perl... but that's not the part I'm talking about. The business logic being encoded as pgpl/* is just fine. But having to write complex triggers that wrap pgpl functions and making sure the state of the functions is as expected and all of the other wiring stuff is just not something most people are used to.

I've recently seen an uptick in "Postgres-native" stuff being built, though. So maybe there's hope for the future.

Yes, this is the true reason why these elegant solutions don't see so much adoption.

Worse is better. Cheap JS devs to solve everything with heaps of imperative code is cheaper than elegant solutions.

Even long term this is true. Tech debt with code that people can understand and modify is cheaper than tech debt with an elegant DSL that require learning and mental ability beyond if then else.

what do datatypes have to do with this. For both PostgREST and any other api layer the situation is the same. The data sits in the db/tabes (so both parties are restricted to the types available in pg) and on the other end you need to output json. The fact that you can have some "smart" internal datatypes in other api layers has 0 advanteges, both systems have to basically take data from the db and display it as json, the intermediate types are irelevant

you can write your stored procedures in JS of Python if you don't like plpgsql that much :)

Reply on news.ycombinator.com