Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Date
Msg-id 16446.1549697160@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> On Sat, Feb 9, 2019 at 9:41 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> +1.  The best solution would presumably be to go through the normal
>> object deletion mechanism; though possibly there's a reason that
>> won't work given you're already inside some other DDL.

> Maybe:
> - CatalogTupleDelete(trigrel, &trigtup->t_self);
> + RemoveTriggerById(trgform->oid)?

No, that's still the back end of the deletion machinery, and in particular
it would fail to clean pg_depend entries for the trigger.  Going in by the
front door would use performDeletion().  (See deleteOneObject() to get
an idea of what's being possibly missed out here.)

            regards, tom lane


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
Next
From: Robert Haas
Date:
Subject: Re: Why don't we have a small reserved OID range for patch revisions?