Hi, I'm with David on this one. Transactional DDL also turns out to be incredibly helpful for tools that generate and load DDL to extend the database, for example triggers and control tables to implement reliable messaging. You can put the setup in a single transaction, which vastly simplifies tool implementation.
We have an application at Continuent that depends on exactly this behavior. I was investigating PostgreSQL semantics just last week and was delighted to find they appear to be exactly right. Oracle on the other hand is going to be a pain... Cheers, Robert Hodges On 1/3/08 12:11 AM, "David Fetter" <[EMAIL PROTECTED]> wrote: > On Thu, Jan 03, 2008 at 01:08:47PM +0530, Gokulakannan Somasundaram wrote: >> On Jan 3, 2008 12:44 PM, Tom Lane <[EMAIL PROTECTED]> wrote: >>> "Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes: >>>> I actually mean to say that DDLs can be declared as >>>> self-committing. >>> >>> Egad, an Oracle lover in our midst. >> >> :). True, its an impact of working more with Oracle. I made the >> suggestion here, because it might reduce some if conditions. >> >>> Most of us think that roll-back-able DDL is one of the best >>> features of Postgres, and certainly one of our best selling points >>> vis-a-vis Oracle. Don't expect us to give it up. >> >> Can you please explain, any specific use-case where DDLs are >> necessary within a transaction? > > Let's imagine that you want to do a DDL change to a production > database. You've tested the change script on a test database, but you > want to be sure you get *exactly* from the place you were to the place > you want to be. With transactional DDL, you know absolutely for sure > that you've done either the whole change or none of it, i.e. not > half-way in between :) > > Cheers, > David (a giant fan of transactional DDL) - Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
