On Jan 3, 2008 12:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Gokulakannan Somasundaram" <gokul007@gmail.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?

--
Thanks,
Gokul.

Alvaro Herrera <alvherre@commandprompt.com> 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 sense to
> try to restrict the user as least as possible.

There's a tradeoff here between security, flexibility, and the amount of
work we want to put into it. At the moment it's not clear to me that
it's worth spending the amount of work that would be needed to determine
which forms of ALTER TABLE are "safe" in this connection. If you're
feeling hot about it, feel free to do the legwork.

(A precedent is that all forms of ALTER TABLE take exclusive lock,
which is more or less the same thing for the cross-backend case.
There's been occasional discussion of whether some forms could
take lesser locks, but never enough interest to make it happen.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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 sense to
>> try to restrict the user as least as possible.
>>
>
> There's a tradeoff here between security, flexibility, and the amount of
> work we want to put into it. At the moment it's not clear to me that
> it's worth spending the amount of work that would be needed to determine
> which forms of ALTER TABLE are "safe" in this connection. If you're
> feeling hot about it, feel free to do the legwork.
>
> (A precedent is that all forms of ALTER TABLE take exclusive lock,
> which is more or less the same thing for the cross-backend case.
> There's been occasional discussion of whether some forms could
> take lesser locks, but never enough interest to make it happen.)
>
>
>

I'd still like to see a sane use case. The other thing being traded off
is possibly simplicity.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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.

> 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.

It sort of does, in that all work under Slony is performed in a
transaction. But Slony attempts to isolate the DDL in a sync at just
the right point, and not mix schema and data changes in syncs.

Still, one of the important best practices in preparing your DDL
changing scripts for Slony is to try running that script inside a
transaction (and then rolling back) on every node, to ensure that it
will in fact work on every node.

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers