> What you have listed is not an actual solution, just a list of things you'd need to solve it Sorry. HN comments is a narrow channel and so I elected not to

> What you have listed is not an actual solution, just a list of things you'd need to solve it Sorry. HN comments is a narrow channel and so I elected not to try to squeeze a full-blown actual solution through it. > I could say the only thing you need for the DSL to SQL solution is a programming language, my list would be one item Well...I enumerated the features of the language I'm using just as you could enumerate the features of your programming language. My list could have one item just as easily as yours can: "PostgreSQL DDL" > how to test this is a valid question as well My answer to that question has been to use pgTAP for testing and postgresql_faker to generate synthetic data https://pgtap.org/ https://pgtap.org/ https://gitlab.com/dalibo/postgresql_faker https://gitlab.com/dalibo/postgresql_faker > My tests also don't require a database to with data in it to test No, but they do require a runtime, be it in Scala or whatever. That's no different from my case where my test runtime is an ephemeral PostgreSQL database. > Do you have an example of how this works if you are performing joins between tables? You bet. https://asciinema.org/a/629243 https://asciinema.org/a/629243 > Does every table need to have some sort of user id in it directly for that to work? It's common for single-database multi-tenant data models to add something like a "tenant_id" to every table. It's simple, more efficient, and more foolproof. You can however just join to other tables in the policy condition as I have done. Extra care should be taken as discussed in the PostgreSQL docs: https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html