Обсуждение: psql and libpq fixes
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
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 existsCREATE 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
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
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
> 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, Pennsylvania19026
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 offDROP TABLE t1;\kill-on-error onCREATE 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
> 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, Pennsylvania19026
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 ...
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. | =====================================================================
> 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, Pennsylvania19026
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
> 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, Pennsylvania19026
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
> > > 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
> > > > 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, Pennsylvania19026
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
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
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!
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!