| From: | Rod Taylor <pg(at)rbt(dot)ca> | 
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> | 
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Transaction aborts on syntax error. | 
| Date: | 2004-02-12 19:13:46 | 
| Message-ID: | 1076613226.10166.217.camel@jester | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
> > > 	BEGIN WORK;
> > > 	LOCK oldtab;
> > > 	CREATE_X TABLE newtab AS SELECT * FROM oldtab;
> > > 	DELETE oldtab;
> > > 	COMMIT
> > > 
> > > In this case, you would want the database to abort on a syntax error, right?
> > 
> > Certainly not if I was typing this from the command line. Imagine the
> > frustration if the typo was in "DELETE oldtab" and the create statement took
> > hours.
> 
> I suppose we could have a SET that psql could set when it was
> interactive and skip rollback on syntax errors, but that is pretty
> exotic.  Also consider that other errors could abort a query aside from
> syntax errors, like deadlocks.
Can this be done entirely on the client side?
Have psql silently wrap every statement going out with a BEGIN and a
COMMIT or ROLLBACK depending on whether there was an error or not?
It depends on subtransactions but those are bound to appear eventually,
and be infinitely more useful.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2004-02-12 19:16:45 | Re: Recursive queries patch | 
| Previous Message | Bruce Momjian | 2004-02-12 18:58:56 | Re: Make length(char(n)) return 'true' length |