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
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 |