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

From Dimitri Fontaine
Subject Re: [HACKERS] pgsql: Add sql_drop event for event triggers
Date
Msg-id m2y5crbsvi.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: [HACKERS] pgsql: Add sql_drop event for event triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] pgsql: Add sql_drop event for event triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Alvaro Herrera <alvherre@2ndquadrant.com> 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 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 switch statement into two of them? The
first one for transaction control statements, and then the other bigger
one.

Maybe we could even rework the code (either in some other switch
statements or just by physical lines proximity) so that TCL, DCL, DDL,
etc are each in easy to spot blocks, which is more or less true as of
today, but not exactly so IIRC.

Then we don't need new support code, and we can even continue using the
current macro.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] pgsql: Add sql_drop event for event triggers
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] pgsql: Add sql_drop event for event triggers