\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/

On 2/8/07, Chad Wagner <chad.wagner@gmail.com> 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,

--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com

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

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

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/

On 2/8/07, Gurjeet Singh <singh.gurjeet@gmail.com> 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. :)

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.

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/

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 Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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/

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/

On 2/9/07, Alvaro Herrera <alvherre@commandprompt.com> 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,

--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com

Gurjeet Singh wrote:

On 2/9/07, Alvaro Herrera <alvherre@commandprompt.com> 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 ;-)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On 2/9/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Gurjeet Singh wrote:

On 2/9/07, Alvaro Herrera <alvherre@commandprompt.com> 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

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

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/

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

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