Sergey Shelukhin wrote
> ORM in this case doesn't execute the failing statements, we do. And
> obviously we want to avoid implementing another "better ORM"
> w/database-specific code for this "side path" if possible, so we just
> stick
> to ANSI SQL (for now).
>
> As for the question itself, I believe the relevant standard (that is
> SQL92)
> is:
> "The execution of a
> <rollback statement>
> may be initiated
> implicitly
> by an implementation when it detects unrecoverable errors. When
> such an error occurs, an exception condition is raised:
> transaction
> rollback with an implementation-defined subclass code."
>
> In no way is a select syntax failure unrecoverable error, although of
> course this section leaves a lot to interpretation...
PostgreSQL waits for an explicit Rollback in your situation - it just keeps
giving you exceptions if you choose not to do so. But if the system were to
crash it is perfectly in its rights to forgo waiting for you to Rollback and
instead do so itself - thus implicitly. Note that this is required so that
savepoint behavior can work properly.
I have and can argue for the behavior you describe but the hurdle to
implement it is very high. I would want some form of "approve error"
command that could be sent (manually in application code or automatically if
interactive) instead of blindly moving forward - MySQL behavior as you
describe is not desireable. In any case syntax errors in application code
are bad but I can see the use for it in interactive mode - but a manual
"approve error" command makes dealing with this distinction somewhat
flexible if you read error causes and are conservative in code when you
approve the error.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/not-aborting-transactions-on-failed-select-tp5770387p5770400.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
