Re: Event trigger code comment duplication

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Event trigger code comment duplication
Дата
Msg-id 20200513051505.GL88791@paquier.xyz
обсуждение исходный текст
Ответ на Re: Event trigger code comment duplication  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Event trigger code comment duplication  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
On Tue, May 12, 2020 at 06:48:51PM -0700, David G. Johnston wrote:
> Whether its a style thing, or some requirement of the C-language, I found
> it odd that the four nearly identical checks were left inline in the
> functions instead of being pulled out into a function.  I've attached a
> conceptual patch that does just this and more clearly presents on my
> thoughts on the topic.  In particular I tried to cleanup the quadruple
> negative sentence (and worse for the whole paragraph) as part of the
> refactoring of the currentEventTriggerState comment.

You may want to check that your code compiles first :)

+bool
+EventTriggerValidContext(bool requireState)
+{
[...]
-   if (!IsUnderPostmaster)
-       return;
+   if (!EventTriggerValidContext(true))
+       return
EventTriggerValidContext() should be static, and the code as written
simply would not compile.

+       if (requireState) {
+           /*
+           * Only move forward if our state is set up.  This is required
+           * to handle concurrency - if we proceed, without state already set up,
+           * and allow EventTriggerCommonSetup to run it may find triggers that
+           * didn't exist when the command started.
+           */
+           if (!currentEventTriggerState)
+               return false;
+       }
Comment format and the if block don't have a format consistent with
the project.

+   /*
+    * See EventTriggerDDLCommandStart for a discussion about why event
+    * triggers are disabled in single user mode.
+    */
+   if (!IsUnderPostmaster)
+       return false;
And here I am pretty sure that you don't want to remove the
explanation why event triggers are disabled in standalone mode.

Note the reason why we don't expect a state being set for
ddl_command_start is present in EventTriggerBeginCompleteQuery():
    /*
     * Currently, sql_drop, table_rewrite, ddl_command_end events are the only
     * reason to have event trigger state at all; so if there are none, don't
     * install one.
     */

Even with all that, I am not sure that we need to complicate further
what we have here.  An empty currentEventTriggerState gets checks in
three places, and each one of them has a slight different of the
reason why we cannot process further, so I would prefer applying my
previous, simple patch if there are no objections to remove the
duplication about event triggers with standalone mode, keeping the
explanations local to each event trigger type, and call it a day.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Problem with logical replication
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: PG 13 release notes, first draft