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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: dealing with extension dependencies that aren't quite 'e'
Date: 2016-01-15 14:49:14
Message-ID: 18108.1452869354@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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:

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

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

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2016-01-15 14:49:37 Limit and inherited tables
Previous Message Robert Haas 2016-01-15 14:03:14 Re: Combining Aggregates