Wow! The fact that you were able to hack this together is really impressive. And here I thought TypeScript would be the second language we support.

I understand if you don't want to take on the additional maintenance burden that another
language would add.

There are a few things that will need to change before we can merge in Kotlin support. The first is a new version of the configuration file that supports multiple language backends. You already noticed that most of the package options don't make sense for Kotlin. I'm tracking that in #302

The interface between parsing, type-checking, and code-generation is still in flux. I don't think it will be frozen any time soon. Have a package for each language is probably a good approach going forward.

that part of the codebase seems to be iterating rapidly, so I decided to just look at Postgres for now.

That's fine, as the first version that ships will be marked experimental. Before we expose it to everyone, we'll need to add MySQL support.

I haven't actually spent that much time working with JDBC before, so some of the generated code could be questionable. More tests will help tell!

I haven't touched Java in years and have never written Kotlin. It would be fantastic if we could get a small group of opinionated Kotlin developers to look at the generated code and make suggestions. Kotlin also has a more featureful type system than Go, so it's possible that the generated code can be more clever.

I had to write a HACK to convert things like $1 to ?

We can do this safely and correctly when parsing queries. We have the full query AST and a means to edit both the AST and the input SQL.

So, where does that leave us? I think it makes sense for this to live in your sqlc fork for the time being. Once the configuration file version has been updated, we can then reassess. In the meantime, I'd focus on porting the tests in examples/authors/db_test.go to Kotlin and getting them running on CI.

Thanks again! I'm really excited about this landing in the future.