Re: [PATCHES] \prompt for psql

2007-02-23 Thread Bruce Momjian

I have applied a modified version of your patch.  I moved the prompt
'text' field as optional before name, and removed the default prompt
string, which seemed un-Unix-like.

I also simplified when stdin/stdout is used.  If stdin is the terminal,
it seems it makes no difference if we use the terminal or stdin.  Now,
prompt uses the terminal unless -f is used.  I think this simplifies its
behavior.  I realize cases where stdin is the terminal and stdout is not
behave differently in the new patch (prompt goes to the terminal and not
to stdout), but I think the previous behavior was too confusing to be
useful.  I can adjust this if people want different behavior.

Update version attached.

---

Chad Wagner wrote:
 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.

[ Attachment, skipping... ]

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

-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/ref/psql-ref.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.186
diff -c -c -r1.186 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml	21 Feb 2007 23:22:42 -	1.186
--- doc/src/sgml/ref/psql-ref.sgml	23 Feb 2007 18:14:04 -
***
*** 1430,1435 
--- 1430,1453 
/varlistentry
  
varlistentry
+ termliteral\prompt [ replaceable class=parametertext/replaceable ] replaceable class=parametername/replaceable/literal/term
+ listitem
+ para
+  Prompts the user to set variable replaceable
+  class=parametername/.  An optional prompt, replaceable
+  class=parametertext/, can be specified.  (For multi-word
+  prompts, use single-quotes.)
+ /para
+ 
+ para
+  By default, literal\prompt/ uses the terminal for input and
+  output.  However, if the option-f/ command line switch is
+  used, literal\prompt/ uses standard input and standard output.
+ /para
+ /listitem
+   /varlistentry
+ 
+   varlistentry
  termliteral\pset replaceable class=parameterparameter/replaceable [ replaceable class=parametervalue/replaceable ]/literal/term
  
  listitem
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.177
diff -c -c -r1.177 command.c
*** src/bin/psql/command.c	5 Jan 2007 22:19:49 -	1.177
--- src/bin/psql/command.c	23 Feb 2007 18:14:06 -
***
*** 712,717 
--- 712,768 
  		free(pw2);
  	}
  
+ 	/* \prompt -- prompt and set variable */
+ 	else if (strcmp(cmd, prompt) == 0)
+ 	{
+ 		char	   *opt, *prompt_text = NULL;
+ 		char	   *arg1, *arg2;
+ 
+ 		arg1 = psql_scan_slash_option(scan_state, 

Re: [PATCHES] \prompt for psql

2007-02-18 Thread Peter Eisentraut
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 [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [PATCHES] \prompt for psql

2007-02-17 Thread Peter Eisentraut
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


Re: [PATCHES] \prompt for psql

2007-02-17 Thread Chad Wagner

On 2/17/07, Peter Eisentraut [EMAIL PROTECTED] 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?


Re: [PATCHES] \prompt for psql

2007-02-17 Thread Magnus Hagander
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


Re: [PATCHES] \prompt for psql

2007-02-17 Thread Bruce Momjian
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  [EMAIL PROTECTED]  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


Re: [PATCHES] \prompt for psql

2007-02-17 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] 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


Re: [PATCHES] \prompt for psql

2007-02-17 Thread Chad Wagner

On 2/17/07, Tom Lane [EMAIL PROTECTED] wrote:


Bruce Momjian [EMAIL PROTECTED] 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.


Re: [PATCHES] \prompt for psql

2007-02-17 Thread Tom Lane
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.

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


Re: [PATCHES] \prompt for psql

2007-02-17 Thread Chad Wagner

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


Re: [PATCHES] \prompt for psql

2007-02-16 Thread Bruce Momjian

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  [EMAIL PROTECTED]  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


Re: [PATCHES] \prompt for psql

2007-02-09 Thread Joshua D. Drake
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/


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

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


Re: [PATCHES] \prompt for psql

2007-02-09 Thread Gurjeet Singh

On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] 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,

--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail | yahoo }.com


Re: [PATCHES] \prompt for psql

2007-02-09 Thread Alvaro Herrera
Gurjeet Singh wrote:
 On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] 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 Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

   http://archives.postgresql.org


Re: [PATCHES] \prompt for psql

2007-02-09 Thread Merlin Moncure

On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] wrote:

Gurjeet Singh wrote:
 On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] 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

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


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Peter Eisentraut
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/

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

   http://archives.postgresql.org


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Gurjeet Singh

On 2/8/07, Chad Wagner [EMAIL PROTECTED] 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,


--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail | yahoo }.com


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Magnus Hagander
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

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

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


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Peter Eisentraut
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/

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Chad Wagner

On 2/8/07, Peter Eisentraut [EMAIL PROTECTED] 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.


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Chad Wagner

On 2/8/07, Gurjeet Singh [EMAIL PROTECTED] 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.  :)


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Chad Wagner

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.


psql_prompt.diff
Description: Binary data

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


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Joshua D. Drake
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/


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

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


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Alvaro Herrera
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 Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

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


Re: [PATCHES] \prompt for psql

2007-02-08 Thread Joshua D. Drake
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/


---(end of broadcast)---
TIP 6: explain analyze is your friend