coding-stylelisted

# PostgreSQL coding-style — operational rules When you touch any `.c` or `.h` under `source/src/`, the file must end up looking like the surrounding code. Follow this checklist; full reasoning and citations live in `knowledge/conventions/coding-style.md`. ## Hard rules (must not violate) ### 1. Indentation: hard tabs, width 4 - Literal `\t`, not spaces. One tab per nesting level. - Verify your editor: `.editorconfig` covers it; if you write a file with spaces, pgindent will produce a noisy diff. ### 2. `#include "postgres.h"` is line 1 of every backend `.c` file Order (each group separated by a blank line): 1. `#include "postgres.h"` (backend) **or** `"postgres_fe.h"` (frontend) **or** `"c.h"` (shared) — **before any system header** 2. `<system headers>` (`<stdio.h>`, `<unistd.h>`, …) 3. `"project headers"` grouped, alphabetical-ish Headers under `src/include/` must compile standalone (`make headerscheck`) and as C++ (`make cpluspluscheck`). ### 3. C99 subset only — these are banned even though C99 has them - No `//` line comments (use `/* … */`) - No variable-length arrays - No declarations interleaved with statements — declare locals at the top of the block before any statement. This includes `for (int i = 0; …)` — declare `i` at the top of the enclosing block. - No universal character names (`\uXXXX`) - Newer features (`_Static_assert`, GCC builtins) require a fallback. ### 4. No raw `malloc` / `free` / `strdup` in the backend Use `palloc` / `pfree` / `repa