Re: dealing with extension dependencies that aren't quite 'e'

On Fri, Jan 15, 2016 at 7:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> writes:
> > I'm looking at an extension that creates some triggers (on user tables)
> > dynamically (i.e., not during CREATE EXTENSION, but afterwards). The
> > author has two problems with it:
>
>
How do these triggers come to be?

> > * «DROP EXTENSION ext» won't work without adding CASCADE, which is an
> > (admittedly relatively minor) inconvenience to users.
>
> I am not sure why that's a bad thing.
>

​Agreed. The triggers the extension creates are not part of the extension
itself and thus should not be removed even if the extension itself is
removed.​

> > * More importantly, pg_dump will dump all those trigger definitions,
> > which is inappropriate in this case because the extension will try
> > to create them.
>
> Or that. Shouldn't pg_dump be expected to restore the same state
> that was there before? IOW, what is the argument that this doesn't
> just represent poorly-thought-through extension behavior?
>

​Also agreed - pending an answer to my question. Restoration involves
recreating the state of the database without "executing" things. It is
assumed that those things not directly created as part of executing "CREATE
EXTENSION" are instead created by "executing" things located in the
extension (e.g., functions) and thus direct re-creation has to occur since
there is no mechanism to execute during restoration.

If there is some sort of catalog-driven user-space population going on the
selection criteria should omit from selection any objects already affected.

This is a bunch of hand-waving, though. It would help to have a concrete
use-case to discuss explicitly rather than espouse theory.

I am not familiar enough with the dependency and extension internals to
comment on the merit of a new kind of dependency type behaving as
described. It sounds like it would allow for a more accurate description
of the internal dependencies of the database - which is good absent any
kind of cost consideration.

David J.