Investigate switching \i to \ir throughout pgxntool

[jnasbyupgrade]

🤖 (Claude)

`\ir` (include relative — resolves the included path relative to the including file's own directory, not the caller's cwd) was added in PostgreSQL 9.2 (2012). pgxntool's declared minimum PostgreSQL version (`META.in.json`, the template it ships for consuming extensions) is 9.5.0 — newer than 9.2 — so `\ir` should be safe to use anywhere pgxntool currently claims support.

`\i` is still used in a few places in this repo (e.g. `test/pgxntool/setup.sql`, `test/pgxntool/tap_setup.sql`, and examples in `README.asc`), presumably because `\ir` didn't exist when they were originally written. Worth investigating switching these to `\ir` by default, since it resolves relative to the including file rather than the caller's cwd — the more robust default for anything that isn't deliberately relying on cwd-relative resolution. If there's a place that genuinely needs `\i`'s cwd-relative behavior, that should get an explicit comment explaining why; everywhere else could just default to `\ir` without needing a comment justifying it, once it's the norm.

Flagging as an investigation, not a confirmed bug — there may be a reason some of these stayed as `\i` that isn't obvious from the current code.

[jnasbyupgrade]

🤖 (Claude)

Further correction, empirically confirmed: \ir's "relative to the including file's own directory" behavior only applies when psql actually has a known current script — i.e. it was invoked via -f filename, or reached via a nested \i/\ir from within another script that itself has a known location. When SQL is instead fed to psql via plain stdin redirection (psql -d dbname < file.sql, with no -f at all), psql has no filename to anchor to, so \ir degenerates to plain cwd-relative resolution — identical to \i.

This matters because pg_regress invokes each test/install SQL file exactly this way (stdin redirection, not -f). Confirmed by direct reproduction: an \ir ../../foo.sql-style include that works correctly when the including file is opened via a nested \i fails with a "no such file" error when the same script is instead piped in via < file, resolving as if it were a plain \i (cwd-relative) all along.

Practical implication for this investigation: it's not just that pgxntool's root-relative \i test/setup.sql-style includes should stay \i (as the prior comment concluded) — it's that switching them to \ir wouldn't even provide the alternative behavior being sought in the first place, given how these files are actually invoked. The same likely applies to any genuine same-directory bare-filename include candidates too, if they're reached the same stdin-fed way rather than via -f/nested \i — worth checking exactly how each candidate file is invoked before assuming \ir changes anything for it.

[jnasbyupgrade]

🤖 (Claude)

Restating a scoping correction (the comment that originally captured this was removed for unrelated reasons; recapping the substance here so the thread stays complete):

\i resolves relative to the psql process's cwd, regardless of how deeply nested the including file is. \ir resolves relative to the including file's own directory. These are only interchangeable when the caller's cwd and the including file's directory happen to coincide — e.g. same-directory, bare-filename includes.

They are NOT interchangeable for the common pgxntool convention of root-relative includes (\i test/setup.sql, \i test/helpers/foo.sql, etc., used throughout test/pgxntool/setup.sql and consuming extensions' own test files) — those work today specifically because pg_regress invokes psql with cwd fixed at the extension root, and \i ignores nesting depth. Converting those to \ir would break them for any file not sitting directly at the extension root (e.g. a two-levels-deep test file doing \ir test/setup.sql would look for a nonexistent path).

So: worth investigating specifically for genuine same-directory, bare-filename include chains (if pgxntool has any) — not the root-relative test/setup.sql-style convention, which should stay \i permanently since it's relying on that cwd-relative behavior deliberately, not by oversight. (See the comment below for a further wrinkle: even for genuine same-directory candidates, \ir only behaves differently from \i when psql actually has a script context — i.e. invoked via -f, not fed via plain stdin redirection.)