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: | Raw Message | Whole Thread | 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 |