Refuse direct PostgreSQL pool opens in the lint

Open Beginner friendly
#459 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
70/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
go, postgresql
Domain
database, tooling

Research direction

Start from the existing forbidigo rule against sql.Open in the repository's lint configuration; the payload does not name that file, so search for forbidigo. Add a matching entry for pgxpool.New, pgxpool.NewWithConfig, stdlib.OpenDB and stdlib.OpenDBFromPool, scoped to production code and excluding test files. Done when the linter flags those calls in production code, test files stay clean, and the existing lint run passes.

Written by the indexing model from the issue text.

Description

enhancement help wanted

What

Add a forbidigo rule against pgxpool.New, pgxpool.NewWithConfig, stdlib.OpenDB and stdlib.OpenDBFromPool in production code, beside the rule against sql.Open. Test code keeps its own pools, since some tests need settings dbkit refuses, such as a pool of one connection.

Why

Every production connection now goes through one pool capped by GOPHENBERG_DATABASE_MAX_CONNS. The rule keeps a second pool from coming back unnoticed.

Dominant language
Go
Stars
293
Forks
50
Avg merge
23h 28m
Merged PRs (30d)
133

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from gopherium/gophenberg

All issues in gopherium/gophenberg

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.