"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Comments?

Why do CREATE/DROP/REINDEX DATABASE no longer call PreventTransactionChain?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Gregory Stark" <stark@enterprisedb.com> writes:

> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> Comments?
>
> Why do CREATE/DROP/REINDEX DATABASE no longer call PreventTransactionChain?

sigh, nevermind.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> Comments?

> Why do CREATE/DROP/REINDEX DATABASE no longer call PreventTransactionChain?

I moved those calls into ProcessUtility to avoid having to pass an extra
argument to those functions. You could call this either way, but there
was already precedent for doing PreventTransactionChain in
ProcessUtility --- several existing commands did it that way. In the
patch as it stands, ProcessUtility does it for every command in which
the call is unconditional, and we only pass isTopLevel to command
subroutines that have some condition or other affecting what to do.
You could make about an equally good case for pushing all those
PreventTransactionChain calls out to the subroutines, but it didn't
really seem any prettier to do it that way.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster