Re: pg_dump with tables created in schemas created by extensions

On 08/27/2016 12:37 AM, Tom Lane wrote:
> =?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= <martin(at)2ndquadrant(dot)com> writes:
>> Looking at this issue today, I found that we are not setting a
>> dependency for an index created inside an extension.
>
> Surely the index has a dependency on a table, which depends on the
> extension?
>
> If you mean that you want an extension to create an index on a table
> that doesn't belong to it, but it's assuming pre-exists, I think
> that's just stupid and we need not support it.
>

I don't see why that would be stupid (and I'm not sure it's up to us to
just decide it's stupid).

Imagine you use extensions to break the application into modules. You
have a "basic" extension, with the table, and a "search" extension
implementing fulltext search on top of that table. Isn't it natural to
keep the gin indexes in the search extension?

So the basic--1.0.sql will do something like

CREATE TABLE x ( ...)

and search--1.0.sql would do

CREATE INDEX y ON x USING gin (z);
CREATE FUNCTION search_objects(..) ...

because the index and function doing the search are somewhat tightly
coupled. I admit this is just an example and I don't know how many
people use extensions this way, but I don't see why this would be
inherently stupid pattern?

I see the current behavior is documented, and I do understand why global
objects can't be part of the extension, but for indexes it seems to
violate POLA a bit.

Is there a reason why we don't want the extension/index dependencies?

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services