Hello,
I have a much clearer picture of the issue. So, does this mean that
with nested transactions, all statements will execute within a
mini-transaction, which may be executed within a branch of user
defined sub-transactions. Such that:
begin
...
...
begin
...
...
mini-tr
Rod Taylor wrote:
> > > > 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?
> > >
> > >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Imagine this:
>
> 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
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> Hmmm I'm not sure how you arrived at this wording for the TODO. How are
>> we defining a "syntax error"?
>
> Parser error, I would say. Misspelling a table name, perhaps.
FWIW, a misspelled table name is plainly a semantic e
Can we clarify what is meant by the client? It is my
expectation/desire that the client library would handle this as a
setting similar to "AutoCommit", which would implicitly protect each
statement within a nested block (savepoint), causing only itself to
abort. Such as, "OnError=>[abort|continue
> Oh, yea, that would be bad. So you want to invalidate the entire
> session on any error? That could be done.
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 359-1001
Well, that's exactly the current behaviour, which crea
Josh Berkus wrote:
> Bruce,
>
> > > So, whatever "error handling mode" conveniences we wish to put in should
> > > be put in on the client side.
> >
> > Added to TODO:
> >
> > * Use nested transactions to prevent syntax errors from aborting
> > ?a transaction
>
> Hmmm I'm
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> which might not be for every statement. Savepoints that you don't
>> actually need are going to be a fairly expensive overhead, AFAICS.
> Well with other db's per statement rollback is a no overhead feature,
> so this is pg specific.
I
Bruce,
> > So, whatever "error handling mode" conveniences we wish to put in should
> > be put in on the client side.
>
> Added to TODO:
>
> * Use nested transactions to prevent syntax errors from aborting
> a transaction
Hmmm I'm not sure how you arrived at this wording
> > It seems to me, that leaving all this to the client (which implicitly
> > inserts savepoints) can never be as efficient as a serverside feature.
>
> I think this is an overly narrow view of "efficiency". With client
> control, the client can insert savepoints whereever it needs them,
Yes, b
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> It seems to me, that leaving all this to the client (which implicitly
> inserts savepoints) can never be as efficient as a serverside feature.
I think this is an overly narrow view of "efficiency". With client
control, the client can inser
> In both cases, the transaction either commits or rollback occurs. No
> other option is possible at the end of the transaction, but in the first
> style of transaction semantics you get a "mid-way" decision point. This
> only refers to retryable errors, since errors like access rights
> violation
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Rod Taylor wrote:
> >> 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?
>
> > Yep, we
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Rod Taylor wrote:
>> 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?
> Yep, we could do it in the client like
>Bruce Momjian
> Simon Riggs wrote:
> > >Tom Lane
> > > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > > Most importantly, other references I have state that: the ANSI
> > SQL-99
> > > > specification does require that if a statement errors then only
that
> > > > statement's changes are rolled bac
>>
In this case, you would want the database to abort on a syntax error, right?
>>
Am I completely off thread to ask why HOW we allow an abort on syntax
errors? (at least in regard to stored functions)
Shouldn't PostgreSQL do somethng intellignet like *notice* the syntax
error in the stored funct
>Bruce Momjian wrote
> Zeugswetter Andreas SB SD wrote:
> >
> > >> Improving on "not ideal" would be good, and would get even closer
to
> > >> full Oracle/SQLServer migration/compatibility. However, since
I've
> never
> > >> looked at that section of code, I couldn't comment on any
particular
> >
> > > 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
Greg Stark wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Imagine this:
> >
> > 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 er
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> It does require that the application be meticulous in its checking though.
> Existing client programs, for instance, may ignore any errors coming back
> from PQexec() during the transaction and just see if the COMMIT succeeds.
> Such could would b
Zeugswetter Andreas SB SD wrote:
>
> >> Improving on "not ideal" would be good, and would get even closer to
> >> full Oracle/SQLServer migration/compatibility. However, since I've never
> >> looked at that section of code, I couldn't comment on any particular
> >> approach nor implement such a ch
On Thu, Feb 12, 2004 at 09:55:36AM +0100, Zeugswetter Andreas SB SD wrote:
>
> Yeah, but in other db's this is solved by the frontend. e.g. in Informix
> dbaccess has a mode that simply stops execution upon first error. So I don't
> think this is a nogo argument, if we added such a feature to psq
>> Improving on "not ideal" would be good, and would get even closer to
>> full Oracle/SQLServer migration/compatibility. However, since I've never
>> looked at that section of code, I couldn't comment on any particular
>> approach nor implement such a change, so I'll shut up and be patient.
>
> I
Simon Riggs wrote:
> I've have tried to work out which section of the manual to document this
> in. The most likely section would seem to be: doc/src/sgml/mvcc.sgml,
> which is the Concurrency Control chapter of the User's Guide (on PDF).
> I'd suggest including an extra sect1 section like this...e
Simon Riggs wrote:
> >Tom Lane
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > Most importantly, other references I have state that: the ANSI
> SQL-99
> > > specification does require that if a statement errors then only that
> > > statement's changes are rolled back.
>
> > > ...if anybody has
>Tom Lane
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Most importantly, other references I have state that: the ANSI
SQL-99
> > specification does require that if a statement errors then only that
> > statement's changes are rolled back.
> > ...if anybody has a copy of the actual spec could th
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Most importantly, other references I have state that: the ANSI SQL-99
> specification does require that if a statement errors then only that
> statement's changes are rolled back.
No. The spec says
The execution of a may be initiated implicit
>Andrej Czapszys
> This is a major bug which greatly diminishes the confidence of my
> co-workers in postgresql.
This is NOT a bug. Transactional robustness is important and PostgreSQL
has a very strict implementation in this area.
>Greg Stark
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Edw
Gavin Sherry wrote:
Its not that there's a rationale behind it. Rather, the existing error
handling code *has* to abort the current transaction because an error has
taken place. In a multi statement transaction block (ie, BEGIN; ...; ...;
... COMMIT;) each statement piggy backs on onto the whole
Greg Stark <[EMAIL PROTECTED]> writes:
> So you picture the backend automatically introducing a mini-nested-transaction
> for every request and automatically rolling that back on any error. So the
> application or user wouldn't have to do anything to continue processing
> ignoring the error?
You'r
Tom Lane <[EMAIL PROTECTED]> writes:
> What it comes down to is that a lot of code in the backend assumes that
> transaction abort can be relied on to do any post-elog cleanup needed,
> such as releasing locks or reclaiming leaked memory. I don't think we
> can afford to give up that assumption;
Greg Stark <[EMAIL PROTECTED]> writes:
> But why does the database enforce that every syntax error *requires* a
> transaction roll back?
PG enforces that every error requires a transaction abort. Period, full
stop. Picking and choosing which errors might not really require a
rollback involves a
On Mon, 8 Feb 2004, Greg Stark wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Edwin S. Ramirez wrote:
> > > Hello,
> > >
> > > Is is possible to change the transaction behaviour not to abort when a
> > > syntax error occurs.
> > >
> > > I've done some searches on the list, and have not
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Edwin S. Ramirez wrote:
> > Hello,
> >
> > Is is possible to change the transaction behaviour not to abort when a
> > syntax error occurs.
> >
> > I've done some searches on the list, and have not found anything.
>
> No, we need nested transactions f
Edwin S. Ramirez wrote:
> Hello,
>
> Is is possible to change the transaction behaviour not to abort when a
> syntax error occurs.
>
> I've done some searches on the list, and have not found anything.
No, we need nested transactions for that. We are working on it or at
least have a plan.
--
On Fri, Jan 30, 2004 at 07:43:06AM -0800, Edwin S. Ramirez wrote:
> Is is possible to change the transaction behaviour not to abort when a
> syntax error occurs.
Not currently.
--
Alvaro Herrera ()
"And as an added bonus, now my computer goes to the toilet for me, leaving me
free to spend time
Hello,
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
I've done some searches on the list, and have not found anything.
-ESR-
---(end of broadcast)---
TIP 6: Have you searched our list archives?
37 matches
Mail list logo
