Andrew Benton

There is an option to use `sqlc` with remote codegen execution, which is perhaps a suitable workaround for Windows PostgreSQL users: https://docs.sqlc.dev/en/stable/reference/changelog.html#remote-code-generation Otherwise the best solution seems to be using...

@Ali-Adel-Nour Your config structure looks like version "1" but you've specified version "2". Your config should parse if you set `version: "1"`.

Coming back to this, we've considered how to use the not null constraint information to add a compile-time check for an insert that will fail but it's not obvious how...

In the named parameter example, I would expect the syntax to be ``` -- @name CreateAuthor :one -- @param @name TEXT NOT NULL -- @param @bio TEXT ``` so that...

> Does this mean we no longer would need `sqlc.narg`? Yes, we just added a bit more clarity about that to the proposal.

I think this might not be enough. Do we not also need to modify the scanning code for the non-nullable enum types so that they properly return a nil pointer...

When you look at the playground example, the correct struct for the view is in `models.go` but the query doesn't use it. So there's something going wrong with the type...

This is indeed a bug with the standard built-in analyzer. I have confirmed the correct behavior (an error saying the `creator_code` column doesn't exist) when using the [database-backed analyzer](https://docs.sqlc.dev/en/stable/howto/generate.html) which...

The correct type for the `Name` field would be `sql.NullString`. With PostgreSQL and the database-backed analyzer turned on that is the result. I would expect a forthcoming MySQL database-backed analyzer...

This is a case where sqlc's built-in type inference isn't good enough. A forthcoming MySQL database-backed analyzer (like [the one we have for PostgreSQL](https://sqlc.dev/posts/2023/10/24/sqlc-v1-23-0-database-backed-analyzer/)) would presumably figure out the type...