Re: pg_dump with tables created in schemas created by extensions

On 08/26/2016 04:15 PM, Tomas Vondra wrote:
> 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).

+1, there are a lot of workflow patterns that make sense and don't make
sense depending on your perspective, consider safe mode with MySQL. I
personally think it is stupid too but it also obviously has a huge
useful user base.

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

It isn't and in fact shows that as we extend Pg, the more we allow
people flexibility in developing WITHIN the database, the more we will
be able to influence them to do so. That is a good thing.

Or maybe we should just tell everyone, use an ORM it will solve all your
problems. (/sarcasm)

Sincerely,

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.