@johnstcn @mafredri thoughts on this?

For:

• No need to update views or materialize them in the DB, sqlc does it all for us.
• Fits in line with our current "generate all the things" process.

Against:

• More complexity in our DB implementation -- now the SQL that you write is not exactly what gets executed.
• We have to maintain a fork of sqlc.
• We could just write the SQL and accompanying boilerplate code ourselves.

We could implement the template before we go to sqlc generation too. Mutate the SQL files that go into SQLc and prevent a fork.

After doing a dive into the SQLc to do this myself, I don't think it is any much easier to do in sqlc.

A large discovery was that although the core of SQLc parses the SQL ast, and you can use that AST to make generation decisions, the actual writing of output SQL is done manually with effectively strings.Replace.

Because of this, if our templates are as simple as a strings.Replace, doing them as a preprocessing step might be more ideal.

However, if that was done, there is no way to use sqlc.embed in a view. So we cannot generated embedded structs. For the current feature, this is ok to be missing, but for more general join support, that is a big loss... So implementing into the core might be required for that, or we also write some post processing step to "merge models".

A positive note of this design is that at any moment we can just move the view to a migration and remove our additional generation code. Or in other words, we have an avenue to roll it back.

I am beginning a conversion with the SQLc maintainer. Going to look into as many options as I can to avoid forking.

The SQLc team expressed that our wants are a common request. I need to follow up with them, but it might not be worth implementing this ourselves manually.

If maintaining the views really hurts, we can come back to this