Re: Does error within transaction imply restarting it?
От | Haroldo Stenger |
---|---|
Тема | Re: Does error within transaction imply restarting it? |
Дата | |
Msg-id | 38F78262.3C66B89D@adinet.com.uy обсуждение исходный текст |
Ответ на | Does error within transaction imply restarting it? (Haroldo Stenger <hstenger@adinet.com.uy>) |
Ответы |
Re: Does error within transaction imply restarting it?
|
Список | pgsql-general |
Ed Loehr wrote: > > Haroldo Stenger wrote: > > 1. A transaction begins > > 2. LOCK TABLE XYZ; is issued. > > 3. Since table XYZ doesn't exist, the backend gives error. > > 4. A CREATE TABLE XYZ(field char); is issued. > > 5. The backend says that it is in abort state, and that all queries will > > be ignored until commit, or end of transaction. > > > > Is this behaviour unavoidable? > > This is problematic (and arguably non-standard) handling of an error within > a transaction, and is a problem for precisely the reason you experienced. > At last check, it appeared some of the key developers might have been > coming around to that understanding, though I'm not sure it has made its > way into any kind of action plan. Thanks, I feel so well of pointing to something worth worrying about. I've been asking elsewhere, whether other DBMSs, behave like or unlike PostgreSQL. I seems that other DBMSs, don't care about erroneous statements within a transaction. Now, I have several paths to follow: 1) Hacking the backend ;-) 2) Hacking the JDBC driver; 3) Hacking GeneXus' generated code. In such hipotetic hacks, I could force not issuing the LOCKs, ignoring'em by the backend, ignoring 'em by the JDBC driver, making'em conditional within the driver, etc. Other ideas, are welcome too. How can I motivate key developers to make their way into an action plan? Cheers, Haroldo.
В списке pgsql-general по дате отправления: