Re: Getting rid of regression test input/ and output/ files

Corey Huinker <corey.huinker@gmail.com>

From: Corey Huinker <corey.huinker@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-12-19T23:41:03Z
Lists: pgsql-hackers
On Sun, Dec 19, 2021 at 5:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Corey Huinker <corey.huinker@gmail.com> writes:
> > I have a nitpick about the \getenv FOO FOO lines.
> > It's a new function to everyone, and to anyone who hasn't seen the
> > documentation it won't be immediately obvious which one is the ENV var
> and
> > which one is the local var. Lowercasing the local var would be a way to
> > reinforce which is which to the reader. It would also be consistent with
> > var naming in the rest of the script.
>
> Reasonable idea.  Another thing I was wondering about was whether
> to attach PG_ prefixes to the environment variable names, since
> those are in a more-or-less global namespace.  If we do that,
> then a different method for distinguishing the psql variables
> is to not prefix them.


+1 to that as well.

Which brings up a tangential question, is there value in having something
that brings in one or more env vars as psql vars directly. I'm thinking
something like:

\importenv pattern [prefix]


(alternate names: \getenv_multi \getenv_pattern, \getenvs, etc)

which could be used like

\importenv PG* env_


which would import PGFOO and PGBAR as env_PGFOO and env_PGBAR, awkward
names but leaving no doubt about where a previously unreferenced variable
came from.

I don't *think* we need it for this specific case, but since the subject of
env vars has come up I thought I'd throw it out there.

Commits

  1. Merge dblink's paths test script into its main test.

  2. Remove dynamic translation of regression test scripts, step 2.

  3. Remove dynamic translation of regression test scripts, step 1.

  4. Add a \getenv command to psql.