Re: Table rewrites vs. pending AFTER triggers

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" <david(at)fetter(dot)org> wrote:

> On Thu, Jan 03, 2008 at 01:08:47PM +0530, Gokulakannan Somasundaram wrote:
>> On Jan 3, 2008 12:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> 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)