From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | AW: [HACKERS] DROP TABLE inside a transaction block |
Date: | 2000-03-06 08:31:30 |
Message-ID: | 219F68D65015D011A8E000006F8590C604AF7D0B@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> >> 3) Implicitly commit the running transaction and begin a new one.
> >> Only Vadim and I support this notion, although this is precisely
> >> what Oracle does (not that that should define PostgreSQL's
> >> behavior, of course). Everyone else, it seems wants to try to
> >> implement #1 successfully...(I don't see it happening any time
> >> soon).
> >
> >I support that too since it also happens to be SQL's idea more or less.
> >One of these days we'll have to offer this as an option. At least for
> >commands for which #1 doesn't work yet.
>
> Do you really mean it when ou say 'Implicitly commit the running
> transaction'. I would be deeply opposed to this philosophically, if so. No
> TX should ever be commited unless the user requests it.
Yes, that was also the general consensus on the list.
No statement is ever going to do an implicit commit of
previous statements.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Jerome ALET | 2000-03-06 09:12:52 | Re: [BUGS] grant/revoke bug with delete/update |
Previous Message | Philip Warner | 2000-03-06 07:27:34 | Re: [HACKERS] DROP TABLE inside a transaction block |