Re: [HACKERS] pgsql: Add sql_drop event for event triggers - Mailing list pgsql-committers

From Tom Lane
Subject Re: [HACKERS] pgsql: Add sql_drop event for event triggers
Date
Msg-id 22310.1367103310@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pgsql: Add sql_drop event for event triggers  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-committers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Yeah, I was just looking at the IfSupported variant.  In the structure
>> I just suggested (separate ProcessSlowUtility function), we could make
>> that work by having switch cases for some statements in both functions,

> I've done it the way you propose here, and then in the Slow variant we
> have two set of cases again: those with some manual transactionnal
> behavior or some other code complexities, and the really simple ones.

I started to look at this patch.  What in the world is the point of
dividing the "slow" function into two separate switches?  Seems like
you might as well put all the cases in the first switch back into
standard_ProcessUtility.

            regards, tom lane


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Incidental cleanup of matviews code.
Next
From: Peter Eisentraut
Date:
Subject: pgsql: pg_dump: Improve message formatting