Date: Tue, 5 Apr 2016 13:08:57 +0530
From: Abhijit Menon-Sen <ams@2ndQuadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: David Steele <david@pgmasters.net>, Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers@postgresql.org,
	Alexander Korotkov <a.korotkov@postgrespro.ru>
Subject: Re: dealing with extension dependencies that aren't quite
 'e'
Message-ID: <20160405073857.GA22826@toroid.org>
References: <20160401123136.GA6379@toroid.org>
 <20160404215503.GA237481@alvherre.pgsql>
 <20160405022530.GA3078@toroid.org>
 <20160405063532.GA20712@toroid.org>
 <20160405070356.GA21967@toroid.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20160405070356.GA21967@toroid.org>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

At 2016-04-05 12:33:56 +0530, ams@2ndQuadrant.com wrote:
>
> Álvaro: I did document and test the extra types you added, but now
> that I think about it a bit more, it's hard to argue that it's useful
> to have a table, for example, depend on an extension. There's really
> nothing about a table that "doesn't work without" an extension.

I think it makes sense to implement this for triggers and functions. It
may also be useful for indexes and materialised views, which can refer
to functions in an extension (and in future, sequences as well).

It's certainly good to know the grammar would work if we wanted to add
other object types in future, but I think we should leave it at that.

Thoughts?

-- Abhijit


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