> Is this what the Transactional DDL feature of postgresql talks about ?
I'd say it's one very small aspect of what's involved in that.
Updates of stored procedures are a relatively trivial matter, because a procedure is defined by just a single catalog entry (one row in pg_proc). So either you see the new version or you see the old version, not much to talk about. The DDL updates that are really interesting ... at least from an implementor's standpoint ... are the ones that involve coordinated changes to multiple catalog entries and some underlying filesystem files as well. In other words, ALTER TABLE. There are not that many other systems that can choose to commit or roll back an arbitrary collection of ALTER TABLE commands.
This doesn't come for free of course. What it mostly costs you in Postgres-land is transient disk space requirements, since we have to store both the "before" and "after" states until commit/rollback.
