Re: [HACKERS] psql setenv command

2011-12-04 Thread Andrew Dunstan



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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-11-28 Thread Josh Kupershmidt
On Sat, Nov 26, 2011 at 11:02 AM, Andrew Dunstan and...@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
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 01f57c4..f97929b 100644
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
*** lo_import 152801
*** 2242,2247 
--- 2242,2265 
  
  
varlistentry
+ termliteral\setenv [ replaceable class=parametername/replaceable [ replaceable class=parametervalue/replaceable ] ]/literal/term
+ 
+ listitem
+ para
+ Sets the environment variable replaceable
+ class=parametername/replaceable to replaceable
+ class=parametervalue/replaceable, or if the
+ replaceable class=parametervalue/replaceable is
+ not supplied, unsets the environment variable. Example:
+ programlisting
+ testdb=gt; userinput\setenv PAGER less/userinput
+ testdb=gt; userinput\setenv LESS -imx4F/userinput
+ /programlisting
+ /para
+ /listitem
+   /varlistentry
+ 
+   varlistentry
  termliteral\sf[+] replaceable class=parameterfunction_description/ /literal/term
  
  listitem
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 9cc73be..e4b4eaa 100644
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*** exec_command(const char *cmd,
*** 1110,1115 
--- 1110,1160 
  		free(opt0);
  	}
  
+ 
+ 	/* \setenv -- set environment command */
+ 	else if (strcmp(cmd, setenv) == 0)
+ 	{
+ 		char	   *envvar = psql_scan_slash_option(scan_state,
+   OT_NORMAL, NULL, false);
+ 		char	   *envval = psql_scan_slash_option(scan_state,
+   OT_NORMAL, NULL, false);
+ 
+ 		if (!envvar)
+ 		{
+ 			psql_error(\\%s: missing required argument\n, cmd);
+ 			success = false;
+ 		}
+ 		else if (strchr(envvar,'=') != NULL)
+ 		{
+ 			psql_error(\\%s: environment variable name must not contain '='\n,
+ 	   cmd);
+ 			success = false;
+ 		}
+ 		else if (!envval)
+ 		{
+ 			/* No argument - unset the environment variable */
+ 			unsetenv(envvar);
+ 			success = true;
+ 		}
+ 		else
+ 		{
+ 			/* Set variable to the value of the next argument */
+ 			int len = strlen(envvar) + strlen(envval) + 1;
+ 			char	   *newval = pg_malloc(len + 1);
+ 
+ 			snprintf(newval, len+1, %s=%s, envvar, envval);
+ 			putenv(newval);
+ 			success = true;
+ 			/*
+ 			 * Do not free newval here, it will screw up the environment
+ 			 * if you do. See putenv man page for details. That means we
+ 			 * leak a bit of memory here, but not enough to worry about.
+ 			 */
+ 		}
+ 		free(envvar);
+ 		free(envval);
+ 	}
+ 
  	/* \sf -- show a function's source code */
  	else if (strcmp(cmd, sf) == 0 || strcmp(cmd, sf+) == 0)
  	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 4649e94..13d8bf6 100644
*** a/src/bin/psql/help.c
--- b/src/bin/psql/help.c
*** slashUsage(unsigned short int pager)
*** 158,164 
  {
  	FILE	   *output;
  
! 	output = PageOutput(93, pager);
  
  	/* if you add/remove a line here, change the row count above */
  
--- 158,164 
  {
  	FILE	   *output;
  
! 	output = PageOutput(94, pager);
  
  	/* if you add/remove a line here, change the row count above */
  
*** slashUsage(unsigned short int pager)
*** 257,262 
--- 257,263 
  
  	fprintf(output, _(Operating System\n));
  	fprintf(output, _(  \\cd [DIR]  change the current working directory\n));
+ 	fprintf(output, _(  \\setenv NAME [VALUE]   set or unset environment variable\n));
  	fprintf(output, _(  \\timing [on|off]   toggle timing of commands (currently %s)\n),
  			ON(pset.timing));
  	fprintf(output, _(  \\! [COMMAND]   execute command in shell or start interactive shell\n));

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-11-26 Thread Andrew Dunstan



On 11/20/2011 11:07 AM, Josh Kupershmidt wrote:

On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstanand...@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


diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 01f57c4..39193d5 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2242,6 +2242,24 @@ lo_import 152801
 
 
   varlistentry
+termliteral\setenv [ replaceable class=parametername/replaceable [ replaceable class=parametervalue/replaceable ] ]/literal/term
+
+listitem
+para
+Sets the environment variable replaceable
+class=parametername/replaceable to replaceable
+class=parametervalue/replaceable, or if the 
+replaceable class=parametervalue/replaceable is
+not supplied, unsets the environment variable. Example:
+programlisting
+foo=gt; userinput\setenv PAGER less/userinput
+foo=gt; userinput\setenv LESS -imx4F/userinput
+/programlisting
+/para
+/listitem
+  /varlistentry
+
+  varlistentry
 termliteral\sf[+] replaceable class=parameterfunction_description/ /literal/term
 
 listitem
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 9cc73be..b5331aa 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -1110,6 +1110,56 @@ exec_command(const char *cmd,
 		free(opt0);
 	}
 
+
+	/* \setenv -- set environment command */
+	else if (strcmp(cmd, setenv) == 0)
+	{
+		char	   *envvar = psql_scan_slash_option(scan_state,
+  OT_NORMAL, NULL, false);
+		char	   *envval = psql_scan_slash_option(scan_state,
+  OT_NORMAL, NULL, false);
+
+		if (!envvar)
+		{
+			psql_error(\\%s: missing required argument\n, cmd);
+			success = false;
+		}
+		else if (strchr(envvar,'=') != NULL)
+		{
+			psql_error(\\%s: environment variable name must not contain '='\n,
+	   cmd);
+			success = false;
+		}
+		else if (!envval)
+		{
+			/* No argument - unset the environment variable */
+			unsetenv(envvar);
+			success = true;
+		}
+		else
+		{
+			/* Set variable to the value of the next argument */
+			int len = strlen(envvar) + strlen(envval) + 1;
+			char	   *newval = pg_malloc(len + 1);
+
+			if (!newval)
+			{
+psql_error(out of memory\n);
+exit(EXIT_FAILURE);
+			}
+			snprintf(newval, len+1, %s=%s, envvar, envval);
+			putenv(newval);
+			success = true;
+			/*
+			 * Do not free newval here, it will screw up the environment
+			 * if you do. See putenv man page for details. That means we
+			 * leak a bit of memory here, but not enough to worry about.
+			 */
+		}
+		free(envvar);
+		free(envval);
+	}
+
 	/* \sf -- show a function's source code */
 	else if (strcmp(cmd, sf) == 0 || strcmp(cmd, sf+) == 0)
 	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 4649e94..20fb5d7 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -158,7 +158,7 @@ slashUsage(unsigned short int pager)
 {
 	FILE	   *output;
 
-	output = PageOutput(93, pager);
+	output = PageOutput(94, pager);
 
 	/* if you add/remove a line here, change the row count above */
 
@@ -257,6 +257,7 @@ slashUsage(unsigned short int pager)
 
 	fprintf(output, _(Operating System\n));
 	fprintf(output, _(  \\cd [DIR]  change the current working directory\n));
+	fprintf(output, _(  \\setenv NAME [VALUE]   set environment variable, or unset it if no value provided\n));
 	fprintf(output, _(  \\timing [on|off]   toggle timing of commands (currently %s)\n),
 			ON(pset.timing));
 	fprintf(output, _(  \\! [COMMAND]   execute command in shell or start interactive shell\n));

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-11-20 Thread Josh Kupershmidt
On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan and...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-11-02 Thread Andrew Dunstan



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\testinsttype ..\..\..\setenv.sql
   \setenv PGFOO foo
   \! echo $PGFOO %PGFOO%
   \setenv PGFOO
   \! echo $PGFOO %PGFOO%
   C:\prog\bf\root\HEAD\testinstbin\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


diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index d6941e0..d8ed5c8 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2237,6 +2237,24 @@ lo_import 152801
 
 
   varlistentry
+termliteral\setenv [ replaceable class=parametername/replaceable [ replaceable class=parametervalue/replaceable ] ]/literal/term
+
+listitem
+para
+Sets the environment variable replaceable
+class=parametername/replaceable to replaceable
+class=parametervalue/replaceable, or if the 
+		replaceable class=parametervalue/replaceable is
+		not supplied, unsets the environment variable. Example:
+programlisting
+foo=gt; userinput\setenv PAGER less/userinput
+foo=gt; userinput\setenv LESS -imx4F/userinput
+/programlisting
+/para
+/listitem
+  /varlistentry
+
+  varlistentry
 termliteral\sf[+] replaceable class=parameterfunction_description/ /literal/term
 
 listitem
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 2c38902..7a91905 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -1104,6 +1104,50 @@ exec_command(const char *cmd,
 		free(opt0);
 	}
 
+
+	/* \setenv -- set environment command */
+	else if (strcmp(cmd, setenv) == 0)
+	{
+		char	   *envvar = psql_scan_slash_option(scan_state,
+  OT_NORMAL, NULL, false);
+		char	   *envval = psql_scan_slash_option(scan_state,
+  OT_NORMAL, NULL, false);
+
+		if (!envvar)
+		{
+			psql_error(\\%s: missing required argument\n, cmd);
+			success = false;
+		}
+		else if (!envval)
+		{
+			/* No argument - unset the environment variable */
+			unsetenv(envvar);
+			success = true;
+		}
+		else
+		{
+			/* Set variable to the value of the next argument */
+			int len = strlen(envvar) + strlen(envval) + 1;
+			char	   *newval = malloc(len + 1);
+
+			if (!newval)
+			{
+psql_error(out of memory\n);
+exit(EXIT_FAILURE);
+			}
+			snprintf(newval, len+1, %s=%s, envvar, envval);
+			putenv(newval);
+			success = true;
+			/*
+			 * Do not free newval here, it will screw up the environment
+			 * if you do. See putenv man page for details. That means we
+			 * leak a bit of memory here, but not enough to worry about.
+			 */
+		}
+		free(envvar);
+		free(envval);
+	}
+
 	/* \sf -- show a function's source code */
 	else if (strcmp(cmd, sf) == 0 || strcmp(cmd, sf+) == 0)
 	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 53e4cd0..5c2172e 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -158,7 +158,7 @@ slashUsage(unsigned short int pager)
 {
 	FILE	   *output;
 
-	output = PageOutput(93, pager);
+	output = PageOutput(94, pager);
 
 	/* if you add/remove a line here, change the row count above */
 
@@ -257,6 +257,7 @@ slashUsage(unsigned short int pager)
 
 	fprintf(output, _(Operating System\n));
 	fprintf(output, _(  \\cd [DIR]  change the current working directory\n));
+	fprintf(output, _(  \\setenv NAME [VALUE]   set environment variable, or unset it if no value provided\n));
 	fprintf(output, _(  \\timing [on|off]   toggle timing of commands (currently %s)\n),
 			ON(pset.timing));
 	fprintf(output, _(  \\! [COMMAND]   execute command in shell or start interactive shell\n));

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-09-26 Thread Josh Kupershmidt
On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan and...@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.ja...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-09-26 Thread Jeff Janes
On Mon, Sep 26, 2011 at 12:07 PM, Josh Kupershmidt schmi...@gmail.com wrote:
 On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan and...@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.ja...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-09-26 Thread Andrew Dunstan



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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-09-24 Thread Jeff Janes
On Thu, Sep 15, 2011 at 7:46 AM, Andrew Dunstan and...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] psql setenv command

2011-09-15 Thread Andrew Dunstan

As discussed, patch attached.

cheers

andrew


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-09-15 Thread Andrew Dunstan
On Thu, September 15, 2011 10:44 am, Andrew Dunstan wrote:

 As discussed, patch attached.



this time with patch.



setenv.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-09-15 Thread Josh Kupershmidt
On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan and...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql setenv command

2011-09-15 Thread Andrew Dunstan
On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
 On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan and...@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



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers