Robert Haas escribió:
> On Mon, Mar 4, 2013 at 4:59 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > Alvaro Herrera escribió:
> >
> >> I think this is mostly ready to go in. I'll look at your docs, and
> >> unless there are more objections will commit later or early tomorrow.
> >
> > Actually it still needs a bit more work: the error messages in
> > pg_event_trigger_dropped_object need to be reworked. It's a bit
> > annoying that the function throws an error if the function is called in
> > a CREATE command, rather than returning an empty set; or is it just me?
>
> That seems like a reasonable thing to change.
I'm thinking just removing the check altogether, and if the list of
objects dropped is empty, then the empty set is returned. That is, if
you call the function directly in user-invoked SQL, you get empty; if
you call the function in a CREATE event trigger function, you get empty.
Since this makes the boolean "drop_in_progress" useless, it'd be removed
as well.
> I do have
> a bit of concern about the save-and-restore logic for the
> dropped-object list -- it necessitates that the processing of every
> DDL command that can potentially drop objects be bracketed with a
> PG_TRY/PG_CATCH block. While that's relatively easy to guarantee
> today (but doesn't ALTER TABLE need similar handling?), it seems to me
> that it might get broken in the future. How hard would it be to pass
> this information up and down the call stack instead of doing it this
> way?
This would be rather messy, I think; there are too many layers, and too
many different functions.
> Or at least move the save/restore logic into something inside the
> deletion machinery itself so that new callers don't have to worry
> about it?
Hmm, maybe this can be made to work, I'll see about it.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
