4 ms·

I love working directly in plpgsql, it makes it possible to perform all the database logic in the database, effectively presenting a domain-specific API to the

I love working directly in plpgsql, it makes it possible to perform all the database logic in the database, effectively presenting a domain-specific API to the world. This api is then available to any SQL user. It’s like creating a built in CLI for your data. Putting logic directly in the database is much faster at runtime, doesn’t require redundant entity definitions, is substantially more likely to detect schema problems, and is way easier to test. And it removes the dependency on a specific language and toolchain. Your logic is accessible by everyone. Unfortunately, the tooling around managing this stuff is not great. The language is a bit boring; idiomatic upper case is the first thing I get rid of. But it’s the best tool for the job. Far from being “way easier” in application code, plpgsql reduces LOC, improves performance and removes dependencies. If someone on my team ignored all of these benefits, well, I’d explain it to them and show them examples until they “got it”. Way easier than firing them.

icedchai 4y ago
Very few people know plpgsql. Like all stored proc languages (Oracle PL/SQL, etc.) it looks and feels like something out of the 80's. It's annoying to deploy, annoying to debug, annoying to test. Many developers today barely know SQL.
- doctor_eval 4y ago
  It’s easy to make it feel more modern (select ffs from stop_using_all_caps). But it’s an ideal DSL for data manipulation. It’s not particularly annoying to debug - there are logging, and even single step debugging tools available - and it’s so much easier to test than writing unit tests to do the same thing. I agree it’s painful to deploy, but as I’ve discovered this is a tooling problem; it’s not at all intrinsic to the medium. It’s certainly possible to create tooling to make it easier, and who knows? Maybe I’ll have something to show HN one day. > Many developers today barely know SQL. If true - a very big if - it’s an inditement of the industry and the incentives we use, not a reason to avoid something that makes code faster, safer and smaller. Objections to using these languages are a lot more about willingness to learn and try new (old) things, than they are about the capabilities of the platform.

icedchai 4y ago

Very few people know plpgsql. Like all stored proc languages (Oracle PL/SQL, etc.) it looks and feels like something out of the 80's. It's annoying to deploy, annoying to debug, annoying to test. Many developers today barely know SQL.

doctor_eval 4y ago
It’s easy to make it feel more modern (select ffs from stop_using_all_caps). But it’s an ideal DSL for data manipulation. It’s not particularly annoying to debug - there are logging, and even single step debugging tools available - and it’s so much easier to test than writing unit tests to do the same thing. I agree it’s painful to deploy, but as I’ve discovered this is a tooling problem; it’s not at all intrinsic to the medium. It’s certainly possible to create tooling to make it easier, and who knows? Maybe I’ll have something to show HN one day. > Many developers today barely know SQL. If true - a very big if - it’s an inditement of the industry and the incentives we use, not a reason to avoid something that makes code faster, safer and smaller. Objections to using these languages are a lot more about willingness to learn and try new (old) things, than they are about the capabilities of the platform.