Hacker News Reader

Comment by henvic | Hacker News Reader

oh, I also have defined database.PGX (https://github.com/henvic/pgxtutorial/blob/main/internal/dat...), which is a little more scarier. I'll get back about that too, but this one is perhaps even more useless, and there might be a better way to solve the issue I want to try to avoid with it.

View on HN

Yeah, I think in that case, just make a decision as to whether or not you're going to use Pool or Conn in your application code. If you change your mind, just refactor; it's not worth maintaining the interface just to open up the opportunity to change in the future. Pool is probably the right choice forever.

If it's for testing, I'd just skip mocking that out and run the queries against the real database, like you do in the article. Production is going to connect to Postgres and run `select * from foobars`. Might as well run `select * from foobars` in the tests, so I'm not surprised when it doesn't work in production.

It wasn't for testing. I wanted to expose only a limited set of *pgx.Pool that was "safe" to be used from any place. For example, without the Close() function that might be called during gracefully shutdown. I wanted to avoid exposing such things as kind of verification process, and that's a little bit silly.

That's a good reason. I think I would prefer adjusting my linter to detect the unsafe uses. That way, if someone really wants to, they can "// nolint:unsafe_db See discussion in ISSUE-1234".

(I haven't done this, but it does seem very achievable for this use case. See https://disaev.me/p/writing-useful-go-analysis-linter/ and https://golangci-lint.run/contributing/new-linters/)

I didn't look closely, but I think that just wrapping the native struct in an interface without the method someone wants to call will just lead them to `wrapper.(*pgxpool.Pool)` and calling the unsafe method anyway.

Reply on news.ycombinator.com