I’m not sure what part of “I get why this shit is useful” is unclear. The original comment made a statement about the guarantees static typing and the limitati

I’m not sure what part of “I get why this shit is useful” is unclear. The original comment made a statement about the guarantees static typing and the limitations of those guarantees, the response while making some tangentially valid points called it a “funny example” as if it ran counter to those limitations. But it doesn’t, that’s all. In this example you are still doing the same compile time verification at runtime. It’s useful, but it’s not making the same type of guarantee. “ should a DBA really SSH into the machine and run arbitrary schema changes willy-nilly” Such a straw man. No matter what the process is, mistakes happen, organizational communication breaks down, environment variables don’t get set, there are thousands of reasons your database schema won’t be as expected that have nothing to do with a rogue DBA. Who said the DBA in my example was acting willy-nilly? Maybe they are following the process. That doesn’t make the static compiled artifacts just disappear. You can put all kinds of additional guards in. These are mostly outside the type system. Do you believe in your process so thoroughly that you would disable any runtime type checking in sqlx if it had the option? (it doesn’t, for what I thought should be obvious reasons).