SQL: PostgreSQL extensions (PGXS Makefile, *.control, sql/*.sql, pg_regress/TAP tests) are not recognised; scan-build --status-bugs is not a static analyzer run

Ouverte
  • Quelque chose ne va pas ?
#276 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
c, github-actions, postgresql, python, sql
Domaine
build-system, ci-cd, tooling

Piste de recherche

Start with ecosystems/sql.py around sql_project (lines 291-297), which only recognises _TOOL_FILES, Flyway paths and pgTAP, then with tools/wrappers.py:13, which treats scan-build as a transparent launcher. Also check ecosystems/c_cpp/ for missing installcheck/prove handling. Done means a PGXS repo fixture (foo.control, sql/, test/sql) is detected as SQL with its pg_regress tests credited, and scan-build --status-bugs make is no longer read as plain make. This spans several subsystems, so ask a maintainer before starting.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

pgvector and pgaudit are the SQL ecosystem's archetype outside dbt (EXTENSION, MODULE_big, DATA = sql/*.sql, REGRESS =, TAP_TESTS = 1, test/sql + test/expected), yet .sql ×57 is unrecognised and the projects are plain C. Their pg_regress and TAP tests run in every CI job (make installcheck, make prove_installcheck) → "no tests found (CTest or Meson)"; pgvector's mac job runs the Clang Static Analyzer with scan-build --status-bugs make (fails on any finding) → "no static analyzer runs" (scan-build is listed as a transparent wrapper in tools/wrappers.py:13). The matrix that matters is the server version (ankane/setup-postgres postgres-version, 15–20) and the valgrind job (check-ub: yes) is the ecosystem's memory/UB check. dbt-utils' ci.yml runs only on workflow_dispatch and create-table-of-contents.yml has on: [], yet ci-present lists both as CI.

Evidence from the corpus audit

pgvector/pgvector, pgaudit/pgaudit / detection
  • kind: DETECTION
  • actual: map: languages ["C"], ecosystems C/C++, Data, Docker; unrecognised_suffixes: .sql (57 / 2 files),
    .control (1), .out (14 / 1), .pl (48 / 1)
  • expected: SQL detected: both are PostgreSQL extensions, the SQL ecosystem's archetype outside dbt; the control file,
    the PGXS Makefile (EXTENSION, MODULE_big, DATA = sql/*.sql) and test/sql + test/expected are unambiguous
  • evidence: pgvector vector.control:1: comment = 'vector data type and ivfflat and hnsw access methods';
    Makefile:1: EXTENSION = vector; Makefile:5: DATA = $(wildcard sql/*--*--*.sql); pgaudit Makefile:1:
    MODULE_big = pgaudit, Makefile:7: EXTENSION = pgaudit; validator ecosystems/sql.py:291-297 (sql_project)
    recognises only _TOOL_FILES, Flyway/migrations/ paths and pgTAP SELECT plan(; docs/ecosystems/sql.md:3-7
    documents the same list
  • repro: a repo with foo.control, Makefile containing EXTENSION = foo / PGXS := $(shell $(PG_CONFIG) --pgxs),
    sql/foo--1.0.sql, test/sql/a.sql, test/expected/a.out
  • confidence: high
pgvector/pgvector, pgaudit/pgaudit / tests-run
  • kind: FALSE_NEGATIVE
  • actual: FAIL: "no tests found (tests registered with CTest (...) or tests registered with Meson's test() in meson.build)"
  • expected: PASS: pg_regress tests (REGRESS =) and TAP tests (TAP_TESTS = 1, test/t/*.pl) exist and every CI
    job runs them with make installcheck / make prove_installcheck
  • evidence: pgvector Makefile:10-11: TESTS = $(wildcard test/sql/*.sql) / REGRESS = $(patsubst test/sql/%.sql,%,$(TESTS)); Makefile:60: prove_installcheck:; .github/workflows/build.yml:35: - run: make installcheck, :41: - run: make prove_installcheck, :125-126: sudo -u postgres make installcheck /
    sudo -u postgres make prove_installcheck; pgaudit Makefile:12: REGRESS = pgaudit, :15: TAP_TESTS = 1,
    test/test.sh:14: make -C /pgaudit installcheck USE_PGXS=1; validator: no installcheck/pg_regress/prove
    anywhere under ecosystems/c_cpp/ (grep returns nothing)
  • repro: Makefile with REGRESS = a + include $(PGXS), test/sql/a.sql, workflow step run: make installcheck
  • confidence: high
pgvector/pgvector / static-analysis
  • kind: FALSE_NEGATIVE (also UNREAD: no unknown raised)
  • actual: FAIL: "C/C++: no static analyzer runs"
  • expected: PASS (or ERROR in the strict run): the mac job runs the Clang Static Analyzer over the whole build with
    --status-bugs, which fails the job on any finding
  • evidence: .github/workflows/build.yml:77: - run: make clean && $(brew --prefix llvm@$LLVM_VERSION)/bin/scan-build --status-bugs make; validator tools/wrappers.py:13: *((name,) for name in ("emcmake", "emmake", "emconfigure", "scan-build", "ccache", "sccache")) lists scan-build as a transparent launcher, so even a plain scan-build make
    is read as make; the $(brew --prefix ...)/bin/ program prefix is a command substitution, yet the strict .txt
    has no ERROR for static-analysis (strict and allow outputs are identical)
  • repro: workflow step run: scan-build --status-bugs make on a C project with a Makefile
  • confidence: high (that it is not credited); medium (which of the two causes applies here)
pgvector/pgvector / platform-matrix, sanitizers
  • kind: UNSUPPORTED
  • actual: platform-matrix PASS "3 OS(es), 3 compiler(s)"; sanitizers FAIL "no sanitizers found"
  • expected: the matrix that matters for a Postgres extension is the server version (15-20 here, via
    ankane/setup-postgres postgres-version), and the valgrind job (ankane/setup-postgres-valgrind, check-ub: yes)
    is the ecosystem's memory/UB check; neither is known
  • evidence: .github/workflows/build.yml:11-22 matrix postgres: 20 ... 15; :27: postgres-version: ${{ matrix.postgres }}; :136-139: - uses: ankane/setup-postgres-valgrind@v1 / postgres-version: 18 /
    check-ub: yes; validator: grep -rn valgrind project_validator/ returns nothing
  • repro: unclear (new tool knowledge)
  • confidence: medium
dbt-labs/dbt-utils / ci-present
  • kind: MESSAGE
  • actual: PASS: lists .github/workflows/ci.yml and .github/workflows/create-table-of-contents.yml as CI; the strict
    run's ERRORs cascade from ci.yml's reusable workflow
  • expected: a note that ci.yml runs only on workflow_dispatch (its automatic triggers are commented out) and
    create-table-of-contents.yml never runs (on: []): the project's actual CI is CircleCI
  • evidence: .github/workflows/ci.yml:12-19: # Automatic triggers temporarily disabled while investigating ... /
    workflow_dispatch:; .github/workflows/create-table-of-contents.yml:8: on: []
  • repro: a workflow with on: []
  • confidence: medium

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.