RE: JDBC Drop/Create problem?
От | Peter Mount |
---|---|
Тема | RE: JDBC Drop/Create problem? |
Дата | |
Msg-id | 1B3D5E532D18D311861A00600865478CF1B638@exchange1.nt.maidstone.gov.uk обсуждение исходный текст |
Ответ на | JDBC Drop/Create problem? (Greg Speegle <Greg@10happythings.com>) |
Ответы |
RE: JDBC Drop/Create problem?
|
Список | pgsql-interfaces |
I'm not sure if the term's "aborted" (been a horrible week, etc), but as the drop failed, any transaction its contained within must also fail - thats the point of transactions. If it didn't then you could find complex relationships breaking down all over the place. What would be nice would be nested transactions. Then the drop could be placed within its own transaction, and the outer one wouldn't be affected. Peter -- Peter Mount Enterprise Support Officer, Maidstone Borough Council Email: petermount@maidstone.gov.uk WWW: http://www.maidstone.gov.uk All views expressed within this email are not the views of Maidstone Borough Council > -----Original Message----- > From: Greg Speegle [mailto:Greg@10happythings.com] > Sent: Thursday, December 07, 2000 6:19 PM > To: Peter Mount > Cc: pgsql-interfaces@postgresql.org > Subject: Re: [INTERFACES] JDBC Drop/Create problem? > > > > Ah. That explains it. Thanks. > > Out of curiosity, why does the transaction get marked as aborted? I > only ask since others > (e.g. Oracle) don't have this behavior. > > Greg > > Peter Mount wrote: > > > Dropping a non-existent table should throw an exception as > well as mark any > > open transaction as aborted. > > > > I'd say either: > > > > * using autoCommit while checking for existing tables. > > * commit and begin a new transaction afterwards. > > * Use temporary tables, so the table doesn't survive the connection. > > > > Peter > > >
В списке pgsql-interfaces по дате отправления: