From: | Robert Hodges <robert(dot)hodges(at)continuent(dot)com> |
---|---|
To: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>, Andrew Dunstan <adunstan(at)postgresql(dot)org> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Table rewrites vs. pending AFTER triggers |
Date: | 2008-06-02 06:51:29 |
Message-ID: | C468E681.811E%robert.hodges@continuent.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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" <gokul007(at)gmail(dot)com> 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 < adunstan(at)postgresql(dot)org> 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: robert(dot)hodges(at)continuent(dot)com
Mobile: +1-510-501-3728 Skype: hodgesrm
From | Date | Subject | |
---|---|---|---|
Next Message | Asko Oja | 2008-06-02 06:59:37 | Re: Add dblink function to check if a named connection exists |
Previous Message | Robert Hodges | 2008-06-02 06:37:30 | Re: Core team statement on replication in PostgreSQL |