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
> 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'

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: 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

Reply via email to