fooododododo
Re:Show HN: Trilogy – A Reusable, Composable SQL Experiment
on Monday November 25, 2024 @03:24PM (#42239820)
Curious what your opinion on plpgsql functions is? Could easily solve your initial problem (if I follow). They don't seem to come up much though
Re:Show HN: Trilogy – A Reusable, Composable SQL Experiment
on Monday November 25, 2024 @03:22PM (#42239795)
Do they ever write plpgsql? If not why not?
Re:Why Pg_dump Is Amazing
on Saturday November 09, 2024 @05:09PM (#42097214)
Is everything in pgdump in the information schema?
Re:Don't use your ORM entities for everything – embrace the SQL
on Friday March 29, 2024 @05:31PM (#39869235)
Why not run Pg in a container if that's what's in prod?
Re:Databases are the endgame for data-oriented design
on Friday December 08, 2023 @02:56PM (#38573403)
Agree re trigger maintenance
Re orm, I'm strongly biased towards only using them when they (1) are absolutely necessary or provide some extreme benefit (2) are able to output the raw SQL to be executed on the db (3) the SQL to be executed is understood.
I've seen them used as a substitute for understanding SQL/databases and, personally, think that's a pretty bad idea.
Re:Databases are the endgame for data-oriented design
on Thursday December 07, 2023 @01:24PM (#38559853)
Tracking triggers etc is pretty straightforward, just put them in a repo and apply them as part of a schema change. Testing them can be tricky, as unit tests aren't as likely to capture the locks/time that can be an issue when the database is under load. Tools like pgreplay can be helpful here.