Thread: 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.
Attachment
On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan <andrew@dunslane.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@dunslane.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@dunslane.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@dunslane.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.janes@gmail.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@gmail.com> wrote: > On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan <andrew@dunslane.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.janes@gmail.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
Attachment
On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan <andrew@dunslane.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@dunslane.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
Attachment
On Sat, Nov 26, 2011 at 11:02 AM, Andrew Dunstan <andrew@dunslane.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
Attachment
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