On Sun, 19 Dec 2021 at 18:41, Corey Huinker wrote:
>
> 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]
Oof. That gives me the security heebie
On 12/18/21 18:53, Tom Lane wrote:
>
> 2. Export the values from pg_regress as environment variables,
> and then add a way for the test scripts to read those variables.
> I was a bit surprised to realize that we didn't have any way
> to do that already --- psql has \setenv, so why did we never
>
Peter Eisentraut writes:
> On 19.12.21 00:53, Tom Lane wrote:
>> I was a bit surprised to realize that we didn't have any way
>> to do that already --- psql has \setenv, so why did we never
>> invent \getenv?
> You can do
> \set foo `echo $ENVVAR`
> but that's probably not portable enough for
On 19.12.21 00:53, Tom Lane wrote:
2. Export the values from pg_regress as environment variables,
and then add a way for the test scripts to read those variables.
I was a bit surprised to realize that we didn't have any way
to do that already --- psql has \setenv, so why did we never
invent
On Sun, Dec 19, 2021 at 7:00 PM Tom Lane wrote:
> Corey Huinker writes:
> > 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]
>
> Meh ...
Corey Huinker writes:
> 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]
Meh ... considering we've gone this long without any getenv capability
in
On Sun, Dec 19, 2021 at 5:48 PM Tom Lane wrote:
> Corey Huinker 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
Corey Huinker 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
>
>
>
> 0001 adds the \getenv command to psql; now with documentation
> and a simple regression test.
>
+1. Wish I had added this years ago when I had a need for it.
>
> 0002 tweaks pg_regress to export the needed values as environment
> variables, and modifies the test scripts to use those
I wrote:
> This led me to wonder why we couldn't get rid of that entire
> mechanism in favor of some less-painful way of getting that
> information into the scripts. If we had the desired values in
> psql variables, we could do what we need easily, for example ...
Here's some fleshed-out patches
I did some desultory investigation of the idea proposed at [1]
that we should refactor the regression test scripts to try to
reduce their interdependencies. I soon realized that one of
the stumbling blocks to this is that we've tended to concentrate
data-loading COPY commands, as well as C
11 matches
Mail list logo
