Re: psql setenv command

As discussed, patch attached.

cheers

andrew

On Thu, September 15, 2011 10:44 am, Andrew Dunstan wrote:
>
> As discussed, patch attached.
>

this time with patch.

On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> this time with patch.

I think help.c should document the \setenv command. And a link from
the "Environment" section[1] of psql's doc page to the section about
\setenv might help too.

The existing \set command lists all internal variables and their
values when called with no arguments. Perhaps \setenv with no
arguments should work similarly: we could display only those
environment variables interesting to psql if there's too much noise.
Or at least, I think we need some way to check the values of
environment variables inside psql, if we're able to set them from
inside psql. To be fair, I notice that \pset doesn't appear to offer a
way to show its current values either, but maybe that should be fixed
separately as well.

Typo: s/vakue/value/

Josh
--
[1] http://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-ENVIRONMENT

On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
> On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan <andrew(at)dunslane(dot)net>
> wrote:
>> this time with patch.
>
> I think help.c should document the \setenv command. And a link from
> the "Environment" section[1] of psql's doc page to the section about
> \setenv might help too.

Good point.

>
> The existing \set command lists all internal variables and their
> values when called with no arguments. Perhaps \setenv with no
> arguments should work similarly: we could display only those
> environment variables interesting to psql if there's too much noise.
> Or at least, I think we need some way to check the values of
> environment variables inside psql, if we're able to set them from
> inside psql. To be fair, I notice that \pset doesn't appear to offer a
> way to show its current values either, but maybe that should be fixed
> separately as well.

\! echo $foo

(which is how I tested the patch, of course)

>
> Typo: s/vakue/value/
>

Yeah, I noticed that after, thanks.

cheers

andrew

On Thu, Sep 15, 2011 at 7:46 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> On Thu, September 15, 2011 10:44 am, Andrew Dunstan wrote:
>>
>> As discussed, patch attached.
>>
>
>
> this time with patch.

Hi Andrew,

A description of the \setenv command should show up in the output of \?.

Should there be a regression test for this? I'm not sure how it would
work, as I don't see a cross-platform way to see what the variable is
set to.

Thanks,

Jeff

On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
>> [need way to show current values]
> \! echo $foo
>
> (which is how I tested the patch, of course)

Ah, right. IMO it'd be helpful to mention that echo example in your
changes to psql-ref.sgml, either as part of your example inside the
<programlisting>, or as a suggestion with the rest of the text.

BTW, have you tested this on Windows? I don't have a Windows machine
handy to fool with, but I do see what might be a mess/confusion on
that platform. The MSDN docs claim[1] that putenv() is deprecated in
favor of _putenv(). The code in pg_upgrade uses
SetEnvironmentVariableA on WIN32, while win32env.c has a wrapper
function pgwin32_putenv() around _putenv().

On Sat, Sep 24, 2011 at 5:18 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> A description of the \setenv command should show up in the output of \?.

Yeah, Andrew agreed upthread that help.c should be amended as well,
which would fix \?.

> Should there be a regression test for this?  I'm not sure how it would
> work, as I don't see a cross-platform way to see what the variable is
> set to.

Similar recent psql changes haven't had regression tests included, and
I don't see much of a need here either.

--
[1] http://msdn.microsoft.com/en-US/library/ms235321%28v=VS.80%29.aspx

Josh

On Mon, Sep 26, 2011 at 12:07 PM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
> On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
>>> [need way to show current values]
>> \! echo $foo
>>
>> (which is how I tested the patch, of course)
>
> Ah, right. IMO it'd be helpful to mention that echo example in your
> changes to psql-ref.sgml, either as part of your example inside the
> <programlisting>, or as a suggestion with the rest of the text.
>
> BTW, have you tested this on Windows? I don't have a Windows machine
> handy to fool with, but I do see what might be a mess/confusion on
> that platform. The MSDN docs claim[1] that putenv() is deprecated in
> favor of _putenv(). The code in pg_upgrade uses
> SetEnvironmentVariableA on WIN32, while win32env.c has a wrapper
> function pgwin32_putenv() around _putenv().

I also wondered this and also don't have a Windows build system.

The win32.h uses a macro to turn putenv() into pgwin32_putenv() , so
as long as that macro is in effect I think it should be doing the
right thing. In any event, there are several other places in the
existing code-base that call putenv() in a similar fashion to the new
code, so it if doesn't work I would expect things to already be
falling over.

>
> On Sat, Sep 24, 2011 at 5:18 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> A description of the \setenv command should show up in the output of \?.
>
> Yeah, Andrew agreed upthread that help.c should be amended as well,
> which would fix \?.

Yes, sorry for the accidental nag. I didn't realize that help.c is
what implements \? until after I posted.

>
>> Should there be a regression test for this?  I'm not sure how it would
>> work, as I don't see a cross-platform way to see what the variable is
>> set to.
>
> Similar recent psql changes haven't had regression tests included, and
> I don't see much of a need here either.

I wasn't sure of the convention on that. I intentionally broke a few
\ commands (because that was easier than reading through all of
regress) and it did start failing, but that looks like that is because
those commands are used incidentally as part of other tests, rather
than having tests in their own right.

But in any case, considering that we are both wondering if it works on
Windows, I think that argues that an automatic regression test would
be very handy.

Cheers,

Jeff

On 09/26/2011 05:07 PM, Jeff Janes wrote:
>
> But in any case, considering that we are both wondering if it works on
> Windows, I think that argues that an automatic regression test would
> be very handy.
>
>

I think an automated test should be possible. Something like:

\setenv PGFOO blurfl
\! echo $PGFOO %PGFOO%

and then have a couple of alternative results. When I get time to get
back to this I'll experiment.

cheers

andrew

On 09/26/2011 05:16 PM, Andrew Dunstan wrote:
>
>
> On 09/26/2011 05:07 PM, Jeff Janes wrote:
>>
>> But in any case, considering that we are both wondering if it works on
>> Windows, I think that argues that an automatic regression test would
>> be very handy.
>>
>>
>
> I think an automated test should be possible. Something like:
>
> \setenv PGFOO blurfl
> \! echo $PGFOO %PGFOO%
>
>
> and then have a couple of alternative results. When I get time to get
> back to this I'll experiment.
>
>

I can confirm it does work on Windows:

C:\prog\bf\root\HEAD\testinst>type ..\..\..\setenv.sql
\setenv PGFOO foo
\! echo $PGFOO %PGFOO%
\setenv PGFOO
\! echo $PGFOO %PGFOO%
C:\prog\bf\root\HEAD\testinst>bin\psql -f ..\..\..\setenv.sql postgres
$PGFOO foo
$PGFOO %PGFOO%

I think I agree on reflection with Josh Kupershmidt that we don't need a
regression test for this.

Updated patch is attached - adding to Nov commitfest.

cheers

andrew

On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Updated patch is attached - adding to Nov commitfest.

Review of the v2 patch:

* Submission Review
Patch applies with some fuzz and builds without warnings. I noticed
some tab characters being used in psql-ref.sgml where they shouldn't
be.

* Usability Review
I sort of doubt I'll use the feature myself, but there was at least
one +1 for the feature idea already, so it seems useful enough. That
said, the stated motivation for the patch:

> First, it would be useful to be able to set pager options and possibly other
> settings, so my suggestion is for a \setenv command that could be put in a
> .psqlrc file, something like:

seems like it would be more suited to being set in the user's
~/.profile (perhaps via an 'alias' if you didn't want the changes to
apply globally). So unless I miss something, the real niche for the
patch seems to be for people to interactively change environment
settings while within psql. Again, not something I'm keen on for my
own use, but if others think it's useful, that's good enough for me.

* Coding Review / Nitpicks
The patch implements \setenv via calls to unsetenv() and putenv(). As
the comment notes,

| That means we
| leak a bit of memory here, but not enough to worry about.

which seems true; the man page basically says there's nothing to be
done about the situation.

The calls to putenv() and unsetenv() are done without any real input
checking. So this admittedly-pathological case produces surprising
results:

test=# \setenv foo=bar baz
test=# \! echo $foo
bar=baz

Perhaps 'envvar' arguments with a '=' in the argument should just be
disallowed.

Also, should the malloc() of newval just use pg_malloc() instead?

* Reviewer Review
I haven't tested on Windows.

Josh

On 11/20/2011 11:07 AM, Josh Kupershmidt wrote:
> On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>> Updated patch is attached - adding to Nov commitfest.
> Review of the v2 patch:
>
> * Submission Review
> Patch applies with some fuzz and builds without warnings. I noticed
> some tab characters being used in psql-ref.sgml where they shouldn't
> be.

Fixed.

>
> * Coding Review / Nitpicks
> The patch implements \setenv via calls to unsetenv() and putenv(). As
> the comment notes,
>
> | That means we
> | leak a bit of memory here, but not enough to worry about.
>
> which seems true; the man page basically says there's nothing to be
> done about the situation.
>
> The calls to putenv() and unsetenv() are done without any real input
> checking. So this admittedly-pathological case produces surprising
> results:
>
> test=# \setenv foo=bar baz
> test=# \! echo $foo
> bar=baz
>
> Perhaps 'envvar' arguments with a '=' in the argument should just be
> disallowed.

Done that way.

> Also, should the malloc() of newval just use pg_malloc() instead?

Yes, also done.

Revised patch attached.

cheers

andrew

On Sat, Nov 26, 2011 at 11:02 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> Also, should the malloc() of newval just use pg_malloc() instead?
>
> Yes, also done.

This bit is unnecessary, since pg_malloc() takes care of the error handling:

+ if (!newval)
+ {
+ psql_error("out of memory\n");
+ exit(EXIT_FAILURE);
+ }

Also, the help output for setenv bleeds over an 80-character terminal,
and it seems the rest of the help outputs try to stay under this
limit. And an OCD nitpick: most of the psql-ref.sgml examples show
'testdb' at the prompt, how about we follow along.

Other than those small gripes, the patch looks fine. Attached is an
updated version to save you some keystrokes.

Josh

On 11/28/2011 09:19 PM, Josh Kupershmidt wrote:
>
> Other than those small gripes, the patch looks fine. Attached is an
> updated version to save you some keystrokes.
>
>

Thanks. Committed.

cheers

andrew