Horton

Thread

  1. psql and libpq fixes

    Peter Eisentraut <peter_e@gmx.net> — 2000-02-07T23:08:30Z

    libpq should be back to normal (printing and all). Sorry once again for
the mess.

The psql quoting issue should be fixed as well. As is usual for
hand-crafted parsers, there's probably something I overlooked, so feel
free to bring that to my attention. I haven't done anything about the
echo options yet, although I'm leaning towards "-a".

While we're at it, there's a setting that causes psql to stop execution of
a script on an error (since usually the later commands will be depending
on the successful completion of earlier ones). I was wondering if that
should be the default if you use the -f option.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  2. Re: [HACKERS] psql and libpq fixes

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-08T00:46:30Z

    Peter Eisentraut <peter_e@gmx.net> writes:
> While we're at it, there's a setting that causes psql to stop execution of
> a script on an error (since usually the later commands will be depending
> on the successful completion of earlier ones). I was wondering if that
> should be the default if you use the -f option.

Sounds useful, but you can't make it the default without breaking existing
scripts.  Trivial example is this common idiom:
	DROP TABLE t1;       -- in case it already exists
	CREATE TABLE t1;
	COPY ...

In general, an existing script is not going to be written with the idea
that psql will cut it off at the knees for provoking an error.  If the
author *does* want all the rest of the commands to be skipped on error,
he'll just have written BEGIN and END around the whole script.

			regards, tom lane

  3. Re: [HACKERS] psql and libpq fixes

    Peter Eisentraut <e99re41@docs.uu.se> — 2000-02-08T11:34:58Z

    On Mon, 7 Feb 2000, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > While we're at it, there's a setting that causes psql to stop execution of
> > a script on an error (since usually the later commands will be depending
> > on the successful completion of earlier ones). I was wondering if that
> > should be the default if you use the -f option.
> 
> Sounds useful, but you can't make it the default without breaking existing
> scripts.  Trivial example is this common idiom:
> 	DROP TABLE t1;       -- in case it already exists
> 	CREATE TABLE t1;
> 	COPY ...

Oh yes, good point.

> 
> In general, an existing script is not going to be written with the idea
> that psql will cut it off at the knees for provoking an error.  If the
> author *does* want all the rest of the commands to be skipped on error,
> he'll just have written BEGIN and END around the whole script.

Last time I checked you couldn't roll back a create table. ;)

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  4. Re: [HACKERS] psql and libpq fixes

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-08T15:50:14Z

    Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
>> In general, an existing script is not going to be written with the idea
>> that psql will cut it off at the knees for provoking an error.  If the
>> author *does* want all the rest of the commands to be skipped on error,
>> he'll just have written BEGIN and END around the whole script.

> Last time I checked you couldn't roll back a create table. ;)

Au contraire, rolling back a CREATE works fine.  It's rolling back
a DROP that gives trouble ;-)

This does bring up a thought --- should psql's kill-the-script-on-error
option perhaps zap the script only for errors committed outside of a
transaction block?  I'm not sure how hard it is for psql to keep track
of whether the script is in an xact, so maybe this'd be far harder than
it's worth.  Seems like it deserves some consideration though.

			regards, tom lane

  5. Re: [HACKERS] psql and libpq fixes

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-02-08T16:02:01Z

    > Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> >> In general, an existing script is not going to be written with the idea
> >> that psql will cut it off at the knees for provoking an error.  If the
> >> author *does* want all the rest of the commands to be skipped on error,
> >> he'll just have written BEGIN and END around the whole script.
> 
> > Last time I checked you couldn't roll back a create table. ;)
> 
> Au contraire, rolling back a CREATE works fine.  It's rolling back
> a DROP that gives trouble ;-)
> 
> This does bring up a thought --- should psql's kill-the-script-on-error
> option perhaps zap the script only for errors committed outside of a
> transaction block?  I'm not sure how hard it is for psql to keep track
> of whether the script is in an xact, so maybe this'd be far harder than
> it's worth.  Seems like it deserves some consideration though.

Why is being in a transaction block important?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  6. Re: [HACKERS] psql and libpq fixes

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-02-08T16:29:36Z

    Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> This does bring up a thought --- should psql's kill-the-script-on-error
>> option perhaps zap the script only for errors committed outside of a
>> transaction block?

> Why is being in a transaction block important?

I was thinking that the script might be expecting an error, and have
established a begin-block to limit the effects of the error.

But on third thought, probably the thing that would be really useful
for "expected errors" is if there is a backslash-command that turns on
or off the kill-on-error behavior.  (The command line switch would
merely set the initial state of this flag.)  This way, a script could
use the option in an intelligent fashion:

	\kill-on-error off
	DROP TABLE t1;
	\kill-on-error on
	CREATE TABLE t1;
	...

It'd still have to default to 'off' for backwards compatibility,
unfortunately, but something like this would be really useful.

			regards, tom lane

  7. Re: [HACKERS] psql and libpq fixes

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-02-08T16:38:53Z

    > But on third thought, probably the thing that would be really useful
> for "expected errors" is if there is a backslash-command that turns on
> or off the kill-on-error behavior.  (The command line switch would
> merely set the initial state of this flag.)  This way, a script could
> use the option in an intelligent fashion:
> 
> 	\kill-on-error off
> 	DROP TABLE t1;
> 	\kill-on-error on
> 	CREATE TABLE t1;
> 	...
> 
> It'd still have to default to 'off' for backwards compatibility,
> unfortunately, but something like this would be really useful.

In Informix 4GL, it is ON ERROR STOP and ON ERROR CONTINUE.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  8. RE: [HACKERS] psql and libpq fixes

    Dmitry Samersoff <dms@wplus.net> — 2000-02-08T18:00:30Z

    On 07-Feb-2000 Peter Eisentraut wrote:
> libpq should be back to normal (printing and all). Sorry once again for
> the mess.
> 
> The psql quoting issue should be fixed as well. As is usual for
> hand-crafted parsers, there's probably something I overlooked, so feel
> free to bring that to my attention. I haven't done anything about the
> echo options yet, although I'm leaning towards "-a".
> 
> While we're at it, there's a setting that causes psql to stop execution of
> a script on an error (since usually the later commands will be depending
> on the successful completion of earlier ones). I was wondering if that
> should be the default if you use the -f option.

No!!! 
I have lots script like 
 drop function ....
 create function 
end so on

May be better going to file like
~/.pgdefaults 


-- 
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

  9. Re: [HACKERS] psql and libpq fixes

    Brian E Gallew <geek+@cmu.edu> — 2000-02-10T16:02:32Z

    Then <tgl@sss.pgh.pa.us> spoke up and said:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> This does bring up a thought --- should psql's kill-the-script-on-error
> >> option perhaps zap the script only for errors committed outside of a
> >> transaction block?
> 
> But on third thought, probably the thing that would be really useful
> for "expected errors" is if there is a backslash-command that turns on
> or off the kill-on-error behavior.  (The command line switch would
> merely set the initial state of this flag.)  This way, a script could
> use the option in an intelligent fashion:

Urhm, wouldn't a better idea be to have something like Ingres' "ON
ERROR" and "ON WARNING" settings?  In Ingres esqlc, you can create
functions and then tell Ingres to execute them in the even of a
warning or error.  Also, you can say "ON ERROR CONTINUE" and errors
will then be returned to the application as a status, but otherwise
ignored.

-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@cmu.edu for my public key.                            |
=====================================================================

  10. Re: [HACKERS] psql and libpq fixes

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-02-10T16:06:22Z

    > Urhm, wouldn't a better idea be to have something like Ingres' "ON
> ERROR" and "ON WARNING" settings?  In Ingres esqlc, you can create
> functions and then tell Ingres to execute them in the even of a
> warning or error.  Also, you can say "ON ERROR CONTINUE" and errors
> will then be returned to the application as a status, but otherwise
> ignored.
> 

Yes, seems like those are the accepted words to use.
-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  11. Re: [HACKERS] psql and libpq fixes

    Peter Eisentraut <e99re41@docs.uu.se> — 2000-02-10T16:12:54Z

    On Thu, 10 Feb 2000, Brian E Gallew wrote:

> Then <tgl@sss.pgh.pa.us> spoke up and said:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > >> This does bring up a thought --- should psql's kill-the-script-on-error
> > >> option perhaps zap the script only for errors committed outside of a
> > >> transaction block?
> > 
> > But on third thought, probably the thing that would be really useful
> > for "expected errors" is if there is a backslash-command that turns on
> > or off the kill-on-error behavior.  (The command line switch would
> > merely set the initial state of this flag.)  This way, a script could
> > use the option in an intelligent fashion:

FYI, the commands are
\set EXIT_ON_ERROR
and
\unset EXIT_ON_ERROR
It's a normal psql variable, but incidentally the syntax seems kind of
easy to remember.

> 
> Urhm, wouldn't a better idea be to have something like Ingres' "ON
> ERROR" and "ON WARNING" settings?  In Ingres esqlc, you can create
> functions and then tell Ingres to execute them in the even of a
> warning or error.  Also, you can say "ON ERROR CONTINUE" and errors
> will then be returned to the application as a status, but otherwise
> ignored.

That's very nice and all, but psql doesn't work that way. I'm not sure how
other dbs organize their front-end internally, but that sort of scheme
would really take psql places we might not want it to go, and for which it
hasn't been designed -- namely, to be a programming language.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  12. Re: [HACKERS] psql and libpq fixes

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-02-10T16:16:31Z

    > FYI, the commands are
> \set EXIT_ON_ERROR
> and
> \unset EXIT_ON_ERROR
> It's a normal psql variable, but incidentally the syntax seems kind of
> easy to remember.
> 

Can we change that to the more standard ON_ERROR_STOP?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  13. Re: [HACKERS] psql and libpq fixes

    Peter Eisentraut <e99re41@docs.uu.se> — 2000-02-10T16:18:30Z

    On Thu, 10 Feb 2000, Bruce Momjian wrote:

> > FYI, the commands are
> > \set EXIT_ON_ERROR
> > and
> > \unset EXIT_ON_ERROR
> > It's a normal psql variable, but incidentally the syntax seems kind of
> > easy to remember.
> > 
> 
> Can we change that to the more standard ON_ERROR_STOP?

Consider it done.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  14. Re: [HACKERS] psql and libpq fixes

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-02-10T16:55:00Z

    > > > > FYI, the commands are
> > > > \set EXIT_ON_ERROR
> > > > and
> > > > \unset EXIT_ON_ERROR
> > > > It's a normal psql variable, but incidentally the syntax seems kind of
> > > > easy to remember.
> > > Can we change that to the more standard ON_ERROR_STOP?
> 
> Any chance of multi-word options? Like "\set on error stop"?
> 
> And at least part of the reason other systems can do some error
> recovery is that they decouple the parser from the backend, so the
> parser is carried closer to the client, and the client can be more
> certain about what is being done. But that carries a lot of baggage
> too...
> 
> If/when we do get more decoupling, it might be done through a Corba
> interface, which would allow us to get away from the string-based
> client/server protocol, and will handle typing, marshalling, byte
> ordering, etc more-or-less transparently.
> 

I think we would have to have more need for multi-word setttings than
this one before adding that complexity.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  15. Re: [HACKERS] psql and libpq fixes

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-02-10T17:00:57Z

    > > > FYI, the commands are
> > > \set EXIT_ON_ERROR
> > > and
> > > \unset EXIT_ON_ERROR
> > > It's a normal psql variable, but incidentally the syntax seems kind of
> > > easy to remember.
> > Can we change that to the more standard ON_ERROR_STOP?

Any chance of multi-word options? Like "\set on error stop"?

And at least part of the reason other systems can do some error
recovery is that they decouple the parser from the backend, so the
parser is carried closer to the client, and the client can be more
certain about what is being done. But that carries a lot of baggage
too...

If/when we do get more decoupling, it might be done through a Corba
interface, which would allow us to get away from the string-based
client/server protocol, and will handle typing, marshalling, byte
ordering, etc more-or-less transparently.

                 - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

  16. Re: [HACKERS] psql and libpq fixes

    Peter Eisentraut <e99re41@docs.uu.se> — 2000-02-10T17:23:36Z

    On Thu, 10 Feb 2000, Thomas Lockhart wrote:

> > > > FYI, the commands are
> > > > \set EXIT_ON_ERROR
> > > > and
> > > > \unset EXIT_ON_ERROR
> > > > It's a normal psql variable, but incidentally the syntax seems kind of
> > > > easy to remember.
> > > Can we change that to the more standard ON_ERROR_STOP?
> 
> Any chance of multi-word options? Like "\set on error stop"?

Actually, that command would set "on" to the value of "errorstop". \set
doesn't have any hard-coded parsing rules, like the SQL look-a-similar, it
just sets variables. They can carry configuration information (like the
above), application state (LASTOID), or whatever you want (\set foo `date
%Y` \\ insert into mytbl values (:foo);). Kind of like a shell or Tcl, I
think.

> And at least part of the reason other systems can do some error
> recovery is that they decouple the parser from the backend, so the
> parser is carried closer to the client, and the client can be more
> certain about what is being done. But that carries a lot of baggage
> too...
> 
> If/when we do get more decoupling, it might be done through a Corba
> interface, which would allow us to get away from the string-based
> client/server protocol, and will handle typing, marshalling, byte
> ordering, etc more-or-less transparently.

At that point we may choose to write a completely new client. ;)

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  17. Re: [HACKERS] psql and libpq fixes

    Peter Eisentraut <peter_e@gmx.net> — 2000-02-10T20:16:02Z

    On 2000-02-10, Thomas Lockhart mentioned:

> > > > FYI, the commands are
> > > > \set EXIT_ON_ERROR
> > > > and
> > > > \unset EXIT_ON_ERROR
> > > > It's a normal psql variable, but incidentally the syntax seems kind of
> > > > easy to remember.
> > > Can we change that to the more standard ON_ERROR_STOP?
> 
> Any chance of multi-word options? Like "\set on error stop"?

You can do
	\set 'some string with any character \t\001\n\n' enabled
but that's a little hard to type. ;)

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  18. Re: [HACKERS] psql and libpq fixes

    Michael Meskes <meskes@postgresql.org> — 2000-02-11T06:39:43Z

    On Thu, Feb 10, 2000 at 11:02:32AM -0500, Brian E Gallew wrote:
> Urhm, wouldn't a better idea be to have something like Ingres' "ON
> ERROR" and "ON WARNING" settings?  In Ingres esqlc, you can create

You can do that with ecpg as well. The syntax is exec sql whenever ....
I doubt though that this was about a precompiler but psql. But then esqlc is
a precompiler too.

Michael

-- 
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De           | Use PostgreSQL!

  19. Re: [HACKERS] psql and libpq fixes

    Michael Meskes <meskes@postgresql.org> — 2000-02-11T06:41:10Z

    On Thu, Feb 10, 2000 at 05:12:54PM +0100, Peter Eisentraut wrote:
> That's very nice and all, but psql doesn't work that way. I'm not sure how
> other dbs organize their front-end internally, but that sort of scheme
> would really take psql places we might not want it to go, and for which it
> hasn't been designed -- namely, to be a programming language.

I wonder why we compare apples and oranges here. Of course esqlc was
designed to be parse a programming language while psql is a query tool. 

Michael
-- 
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De           | Use PostgreSQL!