Re: DROP and ddl_command_end. - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: DROP and ddl_command_end.
Date
Msg-id 20200310.125238.266825729791807788.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: DROP and ddl_command_end.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: DROP and ddl_command_end.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Thanks.

At Mon, 9 Mar 2020 13:29:47 -0400, Robert Haas <robertmhaas@gmail.com> wrote in 
> On Mon, Mar 9, 2020 at 3:54 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: shared-memory based stats collector
Next
From: Tom Lane
Date:
Subject: Re: Add an optional timeout clause to isolationtester step.