Tom Lane writes:
> Applied with some further hacking.
Thanks!
> Hmm, that leads me to wonder exactly how extensively the regression
> tests test event triggers, because it sure looked to me like there
> were multiple bugs left in this version.
The first versions of the event triggers patch seri
Dimitri Fontaine writes:
> Tom Lane 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 pr
Dimitri Fontaine writes:
> Tom Lane 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 pr
Tom Lane 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
Alvaro Herrera writes:
> I don't see how inlining could work here. We will end up with a couple
> dozen calls to ProcessSlowUtility inside ProcessUtility, so inlining it
> will be a really poor strategy.
Maybe I should have spent some time thinking about the idea rather than
just writing it down
Dimitri Fontaine wrote:
> Tom Lane writes:
> > RenameStmt:
> > if (stmt allows event triggers)
> > ProcessSlowUtility(...);
> > else
> > ExecRenameStmt(stmt);
> > break;
> >
> > while in ProcessSlowUtility it'd just l
Tom Lane 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,
> perhaps like this:
Ah yes, that's minimal code duplication
Dimitri Fontaine writes:
> Tom Lane writes:
>> Personally, I'd really like to see the InvokeDDLCommandEventTriggers
>> macros go away; that's not a coding style I find nice. If we had a
>> separate switch containing just the event-supporting calls, we could
>> drop that in favor of one invocatio
Robert Haas writes:
> I kind of wonder if there's some way we could split ProcessUtility()
> up into more digestible pieces. I can't really think of a good way to
> do it though, without writing duplicative switches.
I'm thinking a bit about
ProcessUtility()
{
sw
Tom Lane writes:
> Actually ... wait a moment. That does have some attraction independent
> of performance questions, because what Alvaro suggested requires knowing
> which commands support command triggers in two places. Perhaps with
> some refactoring we could end up with no net addition of cr
On Tue, Apr 9, 2013 at 12:07 PM, Tom Lane wrote:
> I wrote:
>> Dimitri Fontaine writes:
>>> What about splitting the big switch statement into two of them? The
>>> first one for transaction control statements, and then the other bigger
>>> one.
>
>> Sounds like considerable uglification to fix a
I wrote:
> Dimitri Fontaine writes:
>> What about splitting the big switch statement into two of them? The
>> first one for transaction control statements, and then the other bigger
>> one.
> Sounds like considerable uglification to fix a performance issue that's
> entirely hypothetical... let's
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think it would be difficult and probably dangerous to have PG_TRY
>> for only some utility commands, so not much to be done about that.
>> The main thing is to not invoke event trigger code for BEGIN/ABORT/SET.
> What about splitting the big switc
Tom Lane writes:
> Alvaro Herrera writes:
>> (Someone might still complain that we cause a PG_TRY in BEGIN
>> TRANSACTION etc. Not sure if this is something we should worry about.
>> Robert did complain about this previously.)
>
> I think it would be difficult and probably dangerous to have PG_T
Alvaro Herrera writes:
> (Someone might still complain that we cause a PG_TRY in BEGIN
> TRANSACTION etc. Not sure if this is something we should worry about.
> Robert did complain about this previously.)
I think it would be difficult and probably dangerous to have PG_TRY
for only some utility c
Tom Lane wrote:
> Alvaro Herrera writes:
> > Add sql_drop event for event triggers
>
> The buildfarm members that use -DCLOBBER_CACHE_ALWAYS don't like this
> patch:
Ah. Andres Freund found it, after Dimitri prodded me on IM after
Andrew's today mailing list post -- the problem is the new
UTILI
Alvaro Herrera writes:
> Add sql_drop event for event triggers
The buildfarm members that use -DCLOBBER_CACHE_ALWAYS don't like this
patch:
***
*** 760,771
FROM generate_series(1, 50) a;
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
UPDATE serializable_updat
17 matches
Mail list logo
