Re: DROP and ddl_command_end.

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: robertmhaas(at)gmail(dot)com
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: DROP and ddl_command_end.
Date: 2020-03-10 03:52:38
Message-ID: 20200310.125238.266825729791807788.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks.

At Mon, 9 Mar 2020 13:29:47 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> On Mon, Mar 9, 2020 at 3:54 AM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > I may be missing something, andt any opinions, thoughts or suggestions
> > are welcome.
>
> Since it's a set-returning function, I would have expected that
> instead of trying to assign the result to a variable, you'd loop over
> it using FOR var IN query.

Yes, right and I know. I intended the sample being simple, but sorry
for the bogus example. But the problem is not there. The problem is,
the trigger is called for DROP, the function returns no tuples. I'm
not sure DROP is the only command to cause the behavior, but if no
tuples means DROP, we should document that behavior. Otherwise, we
need to document something like:

"pg_event_trigger_ddl_commands() may omit some of the commands and may
return no tuples."

But it is quite odd.

> But if that's the problem, the error message is a bit odd.

The error message is correct if we allow zero-tuple return from the
function. Is it useful if we return DROP event with more information
than just DROP <OBJTYPE>?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-03-10 04:09:12 Re: Add an optional timeout clause to isolationtester step.
Previous Message Andres Freund 2020-03-10 03:34:20 Re: shared-memory based stats collector