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
On Sun, Jun 01, 2008 at 11:51:29PM -0700, Robert Hodges wrote:
If you are saying that DDL should be auto-commit, yes, this really does
limit some use cases.
I agree. Transactional DDL is a big feature I'd hate to see go away.
Oracle DBAs I know look with envy on this feature of Postgres.
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
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
On Jan 3, 2008 3:53 PM, Martijn van Oosterhout [EMAIL PROTECTED] wrote:
On Thu, Jan 03, 2008 at 01:08:47PM +0530, Gokulakannan Somasundaram wrote:
Can you please explain, any specific use-case where DDLs are necessary
within a transaction?
I don't think they are ever necessary, they're
Gokulakannan Somasundaram wrote:
Can you please explain, any specific use-case where DDLs are
necessary within a transaction?
SQL-Scripts that create database objects and should either
succeed or have no effect.
Yours,
Laurenz Albe
---(end of
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
Alvaro Herrera [EMAIL PROTECTED] writes:
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.
I disagree. This is an implementation limitation, so it makes
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
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.
I disagree. This is
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.
--
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
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
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.
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
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
14 matches
Mail list logo
