Re: [PATCH] Add pg_get_event_trigger_ddl() function

From: Rithvika Devisetti <devisettirithvika(at)gmail(dot)com>
To: Ian Lawrence Barwick <barwick(at)gmail(dot)com>
Cc: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Add pg_get_event_trigger_ddl() function
Date: 2026-07-21 03:38:18
Message-ID: CA+HR5vhXyZYi6N=8RbPOZOFYmGmt7bZuBm3K+iVhXTaPq+X1jw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Jul 20, 2026 at 6:49 PM Ian Lawrence Barwick <barwick(at)gmail(dot)com>
wrote:

> Hi Jim
>
> 2026年7月21日(火) 0:13 Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>:
> >
> > Hi Ian
> >
> > Thanks for the patch! Here a few comments on v2:
> >
> > == shadow variable ==
> >
> > The function pg_get_event_trigger_ddl_internal has a bool parameter
> > named owner, and its body has a char* with the same name.
>
> Good catch - I note the compiler-level shadow check is only effective
> for variables of the same type, which hadn't occurred to me before.
>
> > == trailing XXX (placeholder?) ==
> >
> > + * CREATE EVENT TRIGGER statement; XXX
>
> Whoops, fixed.
>
> > == typo (2x the) ==
> >
> > + is false, the the corresponding <literal>ENABLE</literal> clause is
>
> Classic typo invisible to the author, fixed.
>
> > === switch without default ==
> >
> > I realise that "switch (evtForm->evtenabled)" already tests all possible
> > values of evtenable, but I'm wondering if we really should let it
> > silently finish the buffer like "ALTER EVENT TRIGGER foo ;" if evtenable
> > ever gets a different value. I'd argue that an error message would be
> > better than a malformed DDL. What do you think?
>
> I did wonder - the corresponding switch statement in pg_dump falls through
> to
> "ENABLE" as the default value, but only calls that if "evtenabled" is
> not 'O' (the
> default), so the addition of some new trigger firing state would result
> in "ALTER EVENT TRIGGER foo ENABLE;" if the code was not updated,
> which is easy to overlook with this kind of setup. On the other hand, I
> can't
> imagine what kind of new trigger firing state might be added, so maybe
> it's more of a theoretical risk. In any case I added an error message, and
> also updated the tests to check each existing firing state is
> correctly rendered.

While looking at that, I did update the comment in
> "src/include/commands/trigger.h"
> to note that the "TRIGGER_*" definitions also apply to pg_event_trigger.
>

Patch applies clean to me, and tests passed. I see a grammatical typo below,
there is an additional "be".

cannot be actually be used in a valid statement

Thanks,

Rithvika

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2026-07-21 04:17:41 Re: sequencesync worker race with REFRESH SEQUENCES
Previous Message JoongHyuk Shin 2026-07-21 02:12:23 Re: [PATCH] Don't call ereport(ERROR) from recovery target GUC assign hooks