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
