From: Tom Lane <tgl@sss.pgh.pa.us>
To: Abhijit Menon-Sen <ams@2ndQuadrant.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: dealing with extension dependencies that aren't quite 'e'
In-reply-to: <20160115062649.GA5068@toroid.org>
References: <20160115062649.GA5068@toroid.org>
Comments: In-reply-to Abhijit Menon-Sen <ams@2ndQuadrant.com>
 message dated "Fri, 15 Jan 2016 11:56:49 +0530"
Date: Fri, 15 Jan 2016 09:49:14 -0500
Message-ID: <18108.1452869354@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Abhijit Menon-Sen <ams@2ndQuadrant.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers