Thread: \prompt for psql
This adds the ability to "prompt" for internal variable input, below are examples:
test=# \prompt x
Enter value for "x": 3
test=# select * from foo where x = :x;
x
---
3
(1 row)
test=# \prompt x Enter x:
Enter x: 4
test=# select * from foo where x = :x;
x
---
4
(1 row)
====
The input is limited to 4k, should be reasonable enough. Patch is against CVS HEAD.
test=# \prompt x
Enter value for "x": 3
test=# select * from foo where x = :x;
x
---
3
(1 row)
test=# \prompt x Enter x:
Enter x: 4
test=# select * from foo where x = :x;
x
---
4
(1 row)
====
The input is limited to 4k, should be reasonable enough. Patch is against CVS HEAD.
Attachment
Chad Wagner wrote: > This adds the ability to "prompt" for internal variable input, below > are examples: > > test=# \prompt x > Enter value for "x": 3 You can do this already approximately so: \echo -n 'Enter value: ' \set x `read && echo $REPLY` Maybe one command is better, though. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On 2/8/07, Chad Wagner <chad.wagner@gmail.com> wrote:
In help.c:slashUsage(), the comment says:
/* if you add/remove a line here, change the row count above */
So I guess, the patch should also include a change to the line:
output = PageOutput(67, pager); => output = PageOutput(68, pager);
Regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
This adds the ability to "prompt" for internal variable input, below are examples:
In help.c:slashUsage(), the comment says:
/* if you add/remove a line here, change the row count above */
So I guess, the patch should also include a change to the line:
output = PageOutput(67, pager); => output = PageOutput(68, pager);
Regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
On Thu, Feb 08, 2007 at 10:17:19AM +0100, Peter Eisentraut wrote: > Chad Wagner wrote: > > This adds the ability to "prompt" for internal variable input, below > > are examples: > > > > test=# \prompt x > > Enter value for "x": 3 > > You can do this already approximately so: > > \echo -n 'Enter value: ' > \set x `read && echo $REPLY` > > Maybe one command is better, though. That also requires a "reasonable shell", which all platforms don't have... //mha
Magnus Hagander wrote: > That also requires a "reasonable shell", which all platforms don't > have... I think doing any sort of reasonable scripting around psql requires a reasonable shell. Or next someone will suggest implementing loops and conditionals in psql. For that matter, I suspect in any shell you can read the required variables beforehand and pass them into psql through arguments. So the use case for reading variables during a psql script seems questionable anyway (without conditionals, at least). -- Peter Eisentraut http://developer.postgresql.org/~petere/
On 2/8/07, Peter Eisentraut <peter_e@gmx.net> wrote:
Yep, in fact that is more or less something similar that I suggested on pgsql-sql yesterday. The only issue I had with it was it doesn't work for Windows and non-UNIX platforms.
You can do this already approximately so:
\echo -n 'Enter value: '
\set x `read && echo $REPLY`
Maybe one command is better, though.
Yep, in fact that is more or less something similar that I suggested on pgsql-sql yesterday. The only issue I had with it was it doesn't work for Windows and non-UNIX platforms.
On 2/8/07, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
Thanks for the tip, in fact I am slipping in "two" lines because I had to break the line. So should this be set to 69 in my patch? Based on the function name alone, I suspect the answer is yes. :)
In help.c:slashUsage(), the comment says:
/* if you add/remove a line here, change the row count above */
So I guess, the patch should also include a change to the line:
output = PageOutput(67, pager); => output = PageOutput(68, pager);
Thanks for the tip, in fact I am slipping in "two" lines because I had to break the line. So should this be set to 69 in my patch? Based on the function name alone, I suspect the answer is yes. :)
Anyways, here is the patch again with the pager output changed from 67 to 69. Feel free to use it or ignore it, I still think it is a useful patch and doesn't necessary imply that users will want looping next (although, I would like to do anonymous PL/pgSQL chunks ;). I just understand how useful internal variables are if you can't get input into them easily on all platforms.
Attachment
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> That also requires a "reasonable shell", which all platforms don't
>> have...
>
> I think doing any sort of reasonable scripting around psql requires a
> reasonable shell. Or next someone will suggest implementing loops and
> conditionals in psql.
... Now that you mention it :)
psql is a shell. It is the postgresql shell. I don't see any problem
with continuing to extend the postgresql shell to a more functional
platform that is independent.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Joshua D. Drake wrote: > Peter Eisentraut wrote: > > Magnus Hagander wrote: > >> That also requires a "reasonable shell", which all platforms don't > >> have... > > > > I think doing any sort of reasonable scripting around psql requires a > > reasonable shell. Or next someone will suggest implementing loops and > > conditionals in psql. > > ... Now that you mention it :) > > psql is a shell. It is the postgresql shell. I don't see any problem > with continuing to extend the postgresql shell to a more functional > platform that is independent. At least it'd help those poor people trying to do conditional COMMIT or ROLLBACK based on the transaction status. Maybe it's not such a bad idea. On the other hand, seeing how the history line numbers patch is still nowhere to be seen, I don't think we should be expecting you to send a patch ... ;-) -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>> Peter Eisentraut wrote:
>>> Magnus Hagander wrote:
>>>> That also requires a "reasonable shell", which all platforms don't
>>>> have...
>>> I think doing any sort of reasonable scripting around psql requires a
>>> reasonable shell. Or next someone will suggest implementing loops and
>>> conditionals in psql.
>> ... Now that you mention it :)
>>
>> psql is a shell. It is the postgresql shell. I don't see any problem
>> with continuing to extend the postgresql shell to a more functional
>> platform that is independent.
>
> At least it'd help those poor people trying to do conditional COMMIT or
> ROLLBACK based on the transaction status. Maybe it's not such a bad
> idea.
>
> On the other hand, seeing how the history line numbers patch is still
> nowhere to be seen, I don't think we should be expecting you to send a
> patch ... ;-)
No one would except it from me, I would just embed python ;)
Sincerely,
Joshua D. Drake
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
>> Joshua D. Drake wrote:
>>> Peter Eisentraut wrote:
>>>> Magnus Hagander wrote:
>>>>> That also requires a "reasonable shell", which all platforms don't
>>>>> have...
>>>> I think doing any sort of reasonable scripting around psql requires a
>>>> reasonable shell. Or next someone will suggest implementing loops and
>>>> conditionals in psql.
>>> ... Now that you mention it :)
>>>
>>> psql is a shell. It is the postgresql shell. I don't see any problem
>>> with continuing to extend the postgresql shell to a more functional
>>> platform that is independent.
>> At least it'd help those poor people trying to do conditional COMMIT or
>> ROLLBACK based on the transaction status. Maybe it's not such a bad
>> idea.
>>
>> On the other hand, seeing how the history line numbers patch is still
>> nowhere to be seen, I don't think we should be expecting you to send a
>> patch ... ;-)
>
> No one would except it from me, I would just embed python ;)
>
or perhaps accept
> Sincerely,
>
> Joshua D. Drake
>
>
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On 2/9/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
The user doesn't need to check the status of the transaction if he just needs to end it. Just fire the END command and it'll take care of whether to COMMIT or ROLLBACK the transaction:
edb=# begin;
BEGIN
edb=# select count(*) from pg_class;
count
-------
280
(1 row)
edb=# select count(*) from pg_class_xyz;
ERROR: relation "pg_class_xyz" does not exist
edb=# end;
ROLLBACK
edb=#
Regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
At least it'd help those poor people trying to do conditional COMMIT or
ROLLBACK based on the transaction status.
The user doesn't need to check the status of the transaction if he just needs to end it. Just fire the END command and it'll take care of whether to COMMIT or ROLLBACK the transaction:
edb=# begin;
BEGIN
edb=# select count(*) from pg_class;
count
-------
280
(1 row)
edb=# select count(*) from pg_class_xyz;
ERROR: relation "pg_class_xyz" does not exist
edb=# end;
ROLLBACK
edb=#
Regards,
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
Gurjeet Singh wrote: > On 2/9/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > > > >At least it'd help those poor people trying to do conditional COMMIT or > >ROLLBACK based on the transaction status. > > > The user doesn't need to check the status of the transaction if he just > needs to end it. Just fire the END command and it'll take care of whether to > COMMIT or ROLLBACK the transaction: Hmm, right. Maybe I was thinking in savepoints, which Merlin Moncure is so fond of complaining of ;-) -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On 2/9/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Gurjeet Singh wrote: > > On 2/9/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > > > > > >At least it'd help those poor people trying to do conditional COMMIT or > > >ROLLBACK based on the transaction status. > > > > > > The user doesn't need to check the status of the transaction if he just > > needs to end it. Just fire the END command and it'll take care of whether to > > COMMIT or ROLLBACK the transaction: > > Hmm, right. Maybe I was thinking in savepoints, which Merlin Moncure is > so fond of complaining of ;-) I'm still looking for a use for them. When I find one, I'll give you a heads up. (just so you know, with savepoints came exception blocks, one of my all time favorite features). anyways, instead of complaining, consider it more of 'hopeful nudging' :-) merlin
Seems the consensus was this was a good idea, and not feature-creep.
It needs SGML documentation, which I will add.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Chad Wagner wrote:
> Anyways, here is the patch again with the pager output changed from 67 to
> 69. Feel free to use it or ignore it, I still think it is a useful patch
> and doesn't necessary imply that users will want looping next (although, I
> would like to do anonymous PL/pgSQL chunks ;). I just understand how useful
> internal variables are if you can't get input into them easily on all
> platforms.
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Seems the consensus was this was a good idea, and not feature-creep. I wonder whether we want this to read from the console, like the password prompts, or from stdin. Not sure which is more useful. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On 2/17/07, Peter Eisentraut <peter_e@gmx.net> wrote:
Good point, I know that Oracle's "prompt" feature reads from stdin. If it were to use stdin, would gets_fromFile be appropriate in place of simple_prompt, or is there other alternatives that would be linked in with psql?
Also on a different issue related to variable substitution, has anyone considered making the variable substitutions automatically "determine" datatype? It is awfully tricky to understand (I am not sure the specific case below is actually documented?) that something like:
\set foo bar
select * from baz where x = :foo
Will not work, and you have to do:
\set foo '\'bar\''
select * from baz where x = :foo
It would be nice if it assumed a char datatype, or something else. Should I post this second half on variable substitution to hackers?
Bruce Momjian wrote:
> Seems the consensus was this was a good idea, and not feature-creep.
I wonder whether we want this to read from the console, like the
password prompts, or from stdin. Not sure which is more useful.
Good point, I know that Oracle's "prompt" feature reads from stdin. If it were to use stdin, would gets_fromFile be appropriate in place of simple_prompt, or is there other alternatives that would be linked in with psql?
Also on a different issue related to variable substitution, has anyone considered making the variable substitutions automatically "determine" datatype? It is awfully tricky to understand (I am not sure the specific case below is actually documented?) that something like:
\set foo bar
select * from baz where x = :foo
Will not work, and you have to do:
\set foo '\'bar\''
select * from baz where x = :foo
It would be nice if it assumed a char datatype, or something else. Should I post this second half on variable substitution to hackers?
Peter Eisentraut wrote: > Bruce Momjian wrote: >> Seems the consensus was this was a good idea, and not feature-creep. > > I wonder whether we want this to read from the console, like the > password prompts, or from stdin. Not sure which is more useful. > I think from stdin. Otherwise it won't be possible to script it at all. Passwords are special, other prompts are not, I think. //Magnus
Magnus Hagander wrote: > Peter Eisentraut wrote: > > Bruce Momjian wrote: > >> Seems the consensus was this was a good idea, and not feature-creep. > > > > I wonder whether we want this to read from the console, like the > > password prompts, or from stdin. Not sure which is more useful. > > > I think from stdin. Otherwise it won't be possible to script it at all. > Passwords are special, other prompts are not, I think. stdin makes it impossible to read a script from stdin and still prompt the user, but I think that is of limited usefulness. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> stdin makes it impossible to read a script from stdin and still prompt
> the user, but I think that is of limited usefulness.
You can always get around that by reading the script with -f instead.
On balance I can see a lot more uses for read-from-stdin than the other;
however, we do need to define what happens if the command appears when
commands are coming from stdin.
regards, tom lane
On 2/17/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Would it make sense to say:
1. if pset.notty is set and '-f' switch is not set then use simple_prompt
-- deals with SQL script redirection case and '-f' is not used, and not interactive
2. else then use gets_fromFile(stdin) <or some other alternative?> (read from stdin)
-- deals with "prompt value" redirection case and '-f' is used, or interactive
It appears that pset.notty will get set to 1 when stdin is not a tty device, which should be the case for redirection.
Bruce Momjian <bruce@momjian.us> writes:
> stdin makes it impossible to read a script from stdin and still prompt
> the user, but I think that is of limited usefulness.
You can always get around that by reading the script with -f instead.
On balance I can see a lot more uses for read-from-stdin than the other;
however, we do need to define what happens if the command appears when
commands are coming from stdin.
Would it make sense to say:
1. if pset.notty is set and '-f' switch is not set then use simple_prompt
-- deals with SQL script redirection case and '-f' is not used, and not interactive
2. else then use gets_fromFile(stdin) <or some other alternative?> (read from stdin)
-- deals with "prompt value" redirection case and '-f' is used, or interactive
It appears that pset.notty will get set to 1 when stdin is not a tty device, which should be the case for redirection.
"Chad Wagner" <chad.wagner@gmail.com> writes:
> Would it make sense to say:
> 1. if pset.notty is set and '-f' switch is not set then use simple_prompt
> 2. else then use gets_fromFile(stdin) <or some other alternative?>
Actually, there's another issue, which is where to send the prompt.
If we're using /dev/tty the answer is clear, but if we're proposing to
read from stdin then it's not necessarily the case that stdout (or even
stderr) is appropriate.
Arguably a prompt is useless except to a human user, so maybe the rule
is "if stdin is a tty according to pset.notty, then prompt to /dev/tty;
otherwise suppress the prompt altogether". Or we could prompt to stderr
instead of /dev/tty in this case. I'm not sure if there are plausible
use-cases where stdin leads to the terminal and stderr doesn't.
Surely there are precedents for this sort of thing in existing programs;
can anyone point to any programs that seem to get it right (or wrong)?
regards, tom lane
On 2/17/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
pset.notty will be set to 1 if either stdin or stdout is not a tty. So in the case where they are redirecting both input and output then it will prompt on /dev/tty, otherwise the prompt would go out on stdout.
I was thinking perhaps it should look at the '-q' quiet switch for determining whether to display prompt at all. So perhaps with a '-q' switch instead of dumping the prompt to stdout it should always be sent to /dev/tty. Also, I think in general most users of this feature that would be "scripting" output (via expect or similar) would probably just use the '-v' switches.
BTW, attached is the latest version of this patch that includes the code (and updates to the psql-ref.sgml) I talked about earlier. Not sure if gets_fromFile is favored, or perhaps the creation of a psql_prompt_var routine that takes into account some of what simple_prompt is doing but considering the logic we are discussing.
"Chad Wagner" <chad.wagner@gmail.com> writes:
> Would it make sense to say:
> 1. if pset.notty is set and '-f' switch is not set then use simple_prompt
> 2. else then use gets_fromFile(stdin) <or some other alternative?>
Actually, there's another issue, which is where to send the prompt.
If we're using /dev/tty the answer is clear, but if we're proposing to
read from stdin then it's not necessarily the case that stdout (or even
stderr) is appropriate.
Arguably a prompt is useless except to a human user, so maybe the rule
is "if stdin is a tty according to pset.notty, then prompt to /dev/tty;
otherwise suppress the prompt altogether". Or we could prompt to stderr
instead of /dev/tty in this case. I'm not sure if there are plausible
use-cases where stdin leads to the terminal and stderr doesn't.
pset.notty will be set to 1 if either stdin or stdout is not a tty. So in the case where they are redirecting both input and output then it will prompt on /dev/tty, otherwise the prompt would go out on stdout.
I was thinking perhaps it should look at the '-q' quiet switch for determining whether to display prompt at all. So perhaps with a '-q' switch instead of dumping the prompt to stdout it should always be sent to /dev/tty. Also, I think in general most users of this feature that would be "scripting" output (via expect or similar) would probably just use the '-v' switches.
BTW, attached is the latest version of this patch that includes the code (and updates to the psql-ref.sgml) I talked about earlier. Not sure if gets_fromFile is favored, or perhaps the creation of a psql_prompt_var routine that takes into account some of what simple_prompt is doing but considering the logic we are discussing.
Attachment
Chad Wagner wrote: > 1. if pset.notty is set and '-f' switch is not set then use > simple_prompt -- deals with SQL script redirection case and '-f' is > not used, and not interactive > 2. else then use gets_fromFile(stdin) <or some other alternative?> > (read from stdin) That seems a bit too complicated. Programs generally shouldn't behave differently depending on whether stdin or stdout are redirected. I was just raising the point because the shell command "read" reads from stdin and is quite useful noninteractively. I'm not sure, however, that the proposed \prompt command has much use in that regard. -- Peter Eisentraut http://developer.postgresql.org/~petere/
I have applied a modified version of your patch. I moved the prompt 'text' field as optional before name, and removed the default prompt string, which seemed un-Unix-like. I also simplified when stdin/stdout is used. If stdin is the terminal, it seems it makes no difference if we use the terminal or stdin. Now, prompt uses the terminal unless -f is used. I think this simplifies its behavior. I realize cases where stdin is the terminal and stdout is not behave differently in the new patch (prompt goes to the terminal and not to stdout), but I think the previous behavior was too confusing to be useful. I can adjust this if people want different behavior. Update version attached. --------------------------------------------------------------------------- Chad Wagner wrote: > On 2/17/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > "Chad Wagner" <chad.wagner@gmail.com> writes: > > > Would it make sense to say: > > > 1. if pset.notty is set and '-f' switch is not set then use > > simple_prompt > > > 2. else then use gets_fromFile(stdin) <or some other alternative?> > > > > Actually, there's another issue, which is where to send the prompt. > > If we're using /dev/tty the answer is clear, but if we're proposing to > > read from stdin then it's not necessarily the case that stdout (or even > > stderr) is appropriate. > > > > Arguably a prompt is useless except to a human user, so maybe the rule > > is "if stdin is a tty according to pset.notty, then prompt to /dev/tty; > > otherwise suppress the prompt altogether". Or we could prompt to stderr > > instead of /dev/tty in this case. I'm not sure if there are plausible > > use-cases where stdin leads to the terminal and stderr doesn't. > > > > pset.notty will be set to 1 if either stdin or stdout is not a tty. So in > the case where they are redirecting both input and output then it will > prompt on /dev/tty, otherwise the prompt would go out on stdout. > > I was thinking perhaps it should look at the '-q' quiet switch for > determining whether to display prompt at all. So perhaps with a '-q' switch > instead of dumping the prompt to stdout it should always be sent to > /dev/tty. Also, I think in general most users of this feature that would be > "scripting" output (via expect or similar) would probably just use the '-v' > switches. > > BTW, attached is the latest version of this patch that includes the code > (and updates to the psql-ref.sgml) I talked about earlier. Not sure if > gets_fromFile is favored, or perhaps the creation of a psql_prompt_var > routine that takes into account some of what simple_prompt is doing but > considering the logic we are discussing. [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/ref/psql-ref.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.186 diff -c -c -r1.186 psql-ref.sgml *** doc/src/sgml/ref/psql-ref.sgml 21 Feb 2007 23:22:42 -0000 1.186 --- doc/src/sgml/ref/psql-ref.sgml 23 Feb 2007 18:14:04 -0000 *************** *** 1430,1435 **** --- 1430,1453 ---- </varlistentry> <varlistentry> + <term><literal>\prompt [ <replaceable class="parameter">text</replaceable> ] <replaceable class="parameter">name</replaceable></literal></term> + <listitem> + <para> + Prompts the user to set variable <replaceable + class="parameter">name</>. An optional prompt, <replaceable + class="parameter">text</>, can be specified. (For multi-word + prompts, use single-quotes.) + </para> + + <para> + By default, <literal>\prompt</> uses the terminal for input and + output. However, if the <option>-f</> command line switch is + used, <literal>\prompt</> uses standard input and standard output. + </para> + </listitem> + </varlistentry> + + <varlistentry> <term><literal>\pset <replaceable class="parameter">parameter</replaceable> [ <replaceable class="parameter">value</replaceable>]</literal></term> <listitem> Index: src/bin/psql/command.c =================================================================== RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v retrieving revision 1.177 diff -c -c -r1.177 command.c *** src/bin/psql/command.c 5 Jan 2007 22:19:49 -0000 1.177 --- src/bin/psql/command.c 23 Feb 2007 18:14:06 -0000 *************** *** 712,717 **** --- 712,768 ---- free(pw2); } + /* \prompt -- prompt and set variable */ + else if (strcmp(cmd, "prompt") == 0) + { + char *opt, *prompt_text = NULL; + char *arg1, *arg2; + + arg1 = psql_scan_slash_option(scan_state, OT_NORMAL, NULL, false); + arg2 = psql_scan_slash_option(scan_state, OT_NORMAL, NULL, false); + + if (!arg1) + { + psql_error("\\%s: missing required argument\n", cmd); + success = false; + } + else + { + char *result; + + if (arg2) + { + prompt_text = arg1; + opt = arg2; + } + else + opt = arg1; + + if (!pset.inputfile) + result = simple_prompt(prompt_text, 4096, true); + else + { + if (prompt_text) + { + fputs(prompt_text, stdout); + fflush(stdout); + } + result = gets_fromFile(stdin); + } + + if (!SetVariable(pset.vars, opt, result)) + { + psql_error("\\%s: error\n", cmd); + success = false; + } + + free(result); + if (prompt_text) + free(prompt_text); + free(opt); + } + } + /* \pset -- set printing parameters */ else if (strcmp(cmd, "pset") == 0) { Index: src/bin/psql/help.c =================================================================== RCS file: /cvsroot/pgsql/src/bin/psql/help.c,v retrieving revision 1.116 diff -c -c -r1.116 help.c *** src/bin/psql/help.c 5 Jan 2007 22:19:49 -0000 1.116 --- src/bin/psql/help.c 23 Feb 2007 18:14:06 -0000 *************** *** 161,167 **** { FILE *output; ! output = PageOutput(67, pager); /* if you add/remove a line here, change the row count above */ --- 161,167 ---- { FILE *output; ! output = PageOutput(69, pager); /* if you add/remove a line here, change the row count above */ *************** *** 184,189 **** --- 184,191 ---- fprintf(output, _(" \\timing toggle timing of commands (currently %s)\n"), ON(pset.timing)); fprintf(output, _(" \\unset NAME unset (delete) internal variable\n")); + fprintf(output, _(" \\prompt [TEXT] NAME\n" + " prompt user to set internal variable\n")); fprintf(output, _(" \\! [COMMAND] execute command in shell or start interactive shell\n")); fprintf(output, "\n"); Index: src/bin/psql/tab-complete.c =================================================================== RCS file: /cvsroot/pgsql/src/bin/psql/tab-complete.c,v retrieving revision 1.158 diff -c -c -r1.158 tab-complete.c *** src/bin/psql/tab-complete.c 7 Feb 2007 00:52:35 -0000 1.158 --- src/bin/psql/tab-complete.c 23 Feb 2007 18:14:07 -0000 *************** *** 542,548 **** "\\e", "\\echo", "\\encoding", "\\f", "\\g", "\\h", "\\help", "\\H", "\\i", "\\l", "\\lo_import", "\\lo_export", "\\lo_list", "\\lo_unlink", ! "\\o", "\\p", "\\password", "\\pset", "\\q", "\\qecho", "\\r", "\\set", "\\t", "\\T", "\\timing", "\\unset", "\\x", "\\w", "\\z", "\\!", NULL }; --- 542,548 ---- "\\e", "\\echo", "\\encoding", "\\f", "\\g", "\\h", "\\help", "\\H", "\\i", "\\l", "\\lo_import", "\\lo_export", "\\lo_list", "\\lo_unlink", ! "\\o", "\\p", "\\password", "\\prompt", "\\pset", "\\q", "\\qecho", "\\r", "\\set", "\\t", "\\T", "\\timing", "\\unset", "\\x", "\\w", "\\z", "\\!", NULL };