Support for pkg/errors?

[alecbz]

@kyleconroy How do you feel about a config option switching the generated code to use pkg/errors? It's API compatible with the standard errors package, so just the import line would have to change.

Should be simple to put together a PR for it, just wanted to get your thoughts before doing it since it's maybe a weirdly-specific option? But we try to use pkg/errors throughout our codebase (mostly for the stack traces) and it'd be a pretty big help to not need to wrap the sqlc-returned errors with errors.WithStack everywhere.

[alecbz]

Another more generic option might be to allow power users to supply their own templates for the generated code?

This implies that the template data structs become a part of sqlc's API, but gives power users a whole lot of flexibility without sqlc having to maintain too many different config options/too much bespoke functionality.

In addition to the pkg/errors change, another thing I've been thinking about is a way to hook in some opencensus tracing stuff that we currently do for all of our db operations. A customizable template would be able to address that too.

[kyleconroy]

I'm happy to add a configuration option for using "pkg/errors". There's a large number of configuration options, but I want to make sure that sqlc is flexible enough to fit into existing code bases.

Before we do that though, have you looked at a package like https://github.com/ngrok/sqlmw? It may offer the right hooks for using pkg/errors and adding OpenCensus tracing without changing any of the code generated by sqlc.

Long term, I'm less excited about templates. xo/xo uses templates, and I think the interface, while powerful, is really complex. If you take a look at the templates we use to generate the Go code, they aren't pretty to look at. The bigger issue is designing the API that the templates expose. Right now I've been very careful to keep those APIs internal, as I don't want the burden of maintaining backwards compatibility at that layer.

Instead, I'd like to offer an API similar to grpc's client-side UnaryInterceptor (https://github.com/grpc/grpc-go/tree/master/examples/features/interceptor). It's just middleware with a different name. The API for the middleware would be smaller than the one necessary for templates, and may give you a similar amount of flexibility.

Thoughts?

[alecbz]

Writing a sql.DB wrapper that does the tracing/error stuff sounds pretty elegant actually, let me try that.