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.
> Here's v6 with docs and regression tests too. Note the new function in
> objectaddress.c; without that, I was getting regression failures because
> catalogs such as pg_amop and pg_default_acl are not present in its
> supporting table.
I agree that this is reasonably close to being committable. 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? 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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
