Subject: Add documentation for PG_ABS_SRCDIR, PG_ABS_BUILDDIR, PG_LIBDIR, PG_DLSUFFIX

From: Michael Paquier <[email-masked]>
Date: Wed, 11 Mar 2026 10:07:39 +0900

Hi all,

d1029bb5a26c has switched the in-core tests suited based on pg_regress
to do path substitutions based on the set of environment variables
listed in $subject, rather than replacements based on input and output
files, generating new files.

These can be really useful for extension developers who maintain SQL
test suites, so how about documenting them?

I'd like to propose the attached patch, for HEAD, so as one does not
need to guess their existence from the SQL files or pg_regress.c.

Thoughts or comments?
--
Michael
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index d80dd46c5fdb..e3c4a0525ad7 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -444,6 +444,59 @@ make check LANG=C ENCODING=EUC_JP
    </para>
   </sect2>
 
+  <sect2 id="regress-run-path-substitution">
+   <title>Path Substitution</title>
+
+   <para>
+    The test suites driven by <command>pg_regress</command> can use the
+    following environment variables for path substitutions:
+
+    <variablelist>
+     <varlistentry>
+      <term><literal>PG_ABS_SRCDIR</literal></term>
+      <listitem>
+       <para>
+        Absolute path to the source directory.
+       </para>
+      </listitem>
+     </varlistentry>
+
+     <varlistentry>
+     <term><literal>PG_ABS_BUILDDIR</literal></term>
+     <listitem>
+      <para>
+       Absolute path to the build directory.
+      </para>
+     </listitem>
+     </varlistentry>
+
+     <varlistentry>
+     <term><literal>PG_DLSUFFIX</literal></term>
+     <listitem>
+      <para>
+       Name of extension for dynamically-loadable modules (e.g.
+       <literal>.so</literal> on Linux).
+      </para>
+     </listitem>
+     </varlistentry>
+
+     <varlistentry>
+     <term><literal>PG_LIBDIR</literal></term>
+     <listitem>
+      <para>
+       Absolute path to dynamic libraries.
+      </para>
+     </listitem>
+     </varlistentry>
+    </variablelist>
+
+    These are useful when dealing with function and object loading
+    that require specific paths to work, like paths defined in a
+    <command>CREATE FUNCTION</command> or <command>LOAD</command>
+    command, for example.
+   </para>
+  </sect2>
+
   <sect2 id="regress-run-custom-settings">
    <title>Custom Server Settings</title>

---

From: zhanghu <[email-masked]>
Date: Wed, 11 Mar 2026 11:10:44 +0800

> need to guess their existence from the SQL files or pg_regress.c.

Hi

The doc changes look good overall. I applied the patch locally and rendered
the documentation to HTML, the new page also looks good.

A few minor nitpicks:

+       <para>

I think we need a "the" before "dynamically-loadable".

The ending "for example" sounds redundant, since "like" already conveys the
meaning of "for example".

Best regards,
Zhang Hu

---

From: Michael Paquier <[email-masked]>
Date: Thu, 12 Mar 2026 06:34:51 +0900

> I think we need a "the" before "dynamically-loadable".

Don't think this one's necessary here, actually, as it refers to a
general concept around modules.

> meaning of "for example".

WFM.
--
Michael

---

From: zhanghu <[email-masked]>
Date: Thu, 12 Mar 2026 09:37:52 +0800

Michael Paquier <[email-masked]> 于2026年3月12日周四 05:34写道：

>  Sounds good.

---

From: Michael Paquier <[email-masked]>
Date: Thu, 12 Mar 2026 16:49:22 +0900

On Thu, Mar 12, 2026 at 08:08:39AM +0800, Chao Li wrote:
> While the inconsistency is already there and a dedicated cleanup
> might not be worthwhile, my preference is still to limit the
> inconsistency. 

Honestly, for some it may come to a difference between American
English (mostly with comma) vs British English (no comma), so at the
end both styles should be OK.  I have let that as-is after considering
the whole with fresher eyes.  One thing that felt missing is a mention
about \getenv, that one would need to be able to reuse these
variables.  Added a paragraph for that, and applied the result.
--
Michael