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. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

On 2/17/07, Peter Eisentraut <peter_e@gmx.net> 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?

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

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

On 2/17/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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.


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

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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly