Hi Gokul, If you are saying that DDL should be auto-commit, yes, this really does limit some use cases.
Transactional DDL is quite helpful for SQL generators, which need to avoid leaving schema half-changed if the application crashes or there¹s a problem with the database that causes a command to fail. SLONY is an example of such a generator where transactional DDL would be helpful though I don¹t know for a fact that SLONY uses it. We have used it in the past for building queues in SQL, which required multiple schema changes for a single queue. In sum, it¹s much easier to implement such tools if you can do a set of schema changes atomically. There are no doubt other use cases as well. Cheers, Robert On 1/2/08 11:04 PM, "Gokulakannan Somasundaram" <[EMAIL PROTECTED]> wrote: > Is there why we allow DDLs inside a transaction and allow it to be rolled > back? If we commit the previous transaction, as soon as we encounter a DDL, > and commit the DDL too (without waiting for commit) will it be affecting some > use cases? > > I actually mean to say that DDLs can be declared as self-committing. That > would get rid of these exceptions. > > Am i missing something? > > Thanks, > Gokul. > > On Jan 3, 2008 12:02 AM, Andrew Dunstan < [EMAIL PROTECTED]> wrote: >> >> >> Simon Riggs wrote: >>> On Tue, 2008-01-01 at 16:09 -0500, Tom Lane wrote: >>> >>> >>>> Paranoia would >>>> suggest forbidding *any* form of ALTER TABLE when there are pending >>>> trigger events, but maybe that's unnecessarily strong. >>>> >>> >>> That works for me. Such a combination makes no sense, so banning it is >>> the right thing to do. >>> >>> >> >> +1. Doesn't make much sense to me either. >> >> cheers >> >> andrew >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 4: Have you searched our list archives? >> >> http://archives.postgresql.org >> <http://archives.postgresql.org> > > > -- Robert Hodges, CTO, Continuent, Inc. Email: [EMAIL PROTECTED] Mobile: +1-510-501-3728 Skype: hodgesrm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
