Adding LastInsertId for Go

[xeoncross]

#1459 adds support for sql.Result.LastInsertId()

:execlastinsertid is calls .LastInsertId() rather than .RowsAffected() with :execrows.

This will avoid the sql.Result database package leaking across the boundary of the pkg.Querier interface generated by sqlc when using MySQL & MariaDB

[kyleconroy]

This will avoid the sql.Result database package leaking across the boundary of the pkg.Querier interface generated by sqlc when using MySQL & MariaDB

I'd rather leak the sql.Result than add another command. The reason is that we already support :execresult. I think adding :execrows was a mistake, so I don't want to make the same mistake twice.

[xeoncross]

Is there anything I can do to change your mind? The fact that the sql.Result leaks out of the models generated means an entire new translation layer must be added between the app and model to get res.LastInsertId() from the sql.Result when using MySQL. This pain does not exist in PostgreSQL, but a lot of companies still rely on MySQL and this means having to either write all the insert id fetching directly in the calling code - or add a model layer to the model layer to hide this extra step.

Can you share more about why :execrows was a mistake? Has that complicated the addition of new languages?

[kyleconroy]

Can you share more about why :execrows was a mistake?

In this case, you're right that it's not much more work to support. Also, there are only two methods on sql.Result, so we aren't going to have to add any more in the future.

[kyleconroy]

Since RowsAffected() maps to :execrows, let's map LastInsertId() to:execlastid.

Also, please add tests similar to exec_rows and exec_result.

[xeoncross]

I tried to add the python generation example, but when I changed into the internal/endtoend/testdata/exec_lastid/python_postgresql folder and run it against my local sqlc it complained:

$ ../../../../../sqlc2 generate
> error parsing sqlc.json: unknown target langauge "python"

I was using the same code from the exec_rows example.

I also wasn't sure what the PGX (go_postgresql_pgx) should be since this isn't something for PostgreSQL - so I left it.

[kyleconroy]

It's okay that you weren't able to add the Python support, can do that in a subsequent PR.

You're also right that we don't need to add support for pgx, as it's Result type does not have this method.