Re: [PATCHES] \prompt for psql
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 [EMAIL PROTECTED] wrote:
Chad Wagner [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 - 1.186
--- doc/src/sgml/ref/psql-ref.sgml 23 Feb 2007 18:14:04 -
***
*** 1430,1435
--- 1430,1453
/varlistentry
varlistentry
+ termliteral\prompt [ replaceable class=parametertext/replaceable ] replaceable class=parametername/replaceable/literal/term
+ listitem
+ para
+ Prompts the user to set variable replaceable
+ class=parametername/. An optional prompt, replaceable
+ class=parametertext/, 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
termliteral\pset replaceable class=parameterparameter/replaceable [ replaceable class=parametervalue/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 - 1.177
--- src/bin/psql/command.c 23 Feb 2007 18:14:06 -
***
*** 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,
Re: [PATCHES] \prompt for psql
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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] \prompt for psql
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] \prompt for psql
On 2/17/07, Peter Eisentraut [EMAIL PROTECTED] 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. 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?
Re: [PATCHES] \prompt for psql
Bruce Momjian [EMAIL PROTECTED] 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 ---(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
Re: [PATCHES] \prompt for psql
On 2/17/07, Tom Lane [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] 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.
Re: [PATCHES] \prompt for psql
Chad Wagner [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] \prompt for psql
On 2/17/07, Tom Lane [EMAIL PROTECTED] wrote: Chad Wagner [EMAIL PROTECTED] 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. psql_prompt2.diff Description: Binary data ---(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
Re: [PATCHES] \prompt for psql
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/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] \prompt for psql
On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] 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: 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, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | yahoo }.com
Re: [PATCHES] \prompt for psql
On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] wrote: Gurjeet Singh wrote: On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] \prompt for psql
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/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] \prompt for psql
On 2/8/07, Chad Wagner [EMAIL PROTECTED] wrote: 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, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | yahoo }.com
Re: [PATCHES] \prompt for psql
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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] \prompt for psql
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] \prompt for psql
On 2/8/07, Peter Eisentraut [EMAIL PROTECTED] wrote: 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.
Re: [PATCHES] \prompt for psql
On 2/8/07, Gurjeet Singh [EMAIL PROTECTED] 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); 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. :)
Re: [PATCHES] \prompt for psql
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. psql_prompt.diff Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] \prompt for psql
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/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] \prompt for psql
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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] \prompt for psql
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
