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.