Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On 08/27/2016 12:37 AM, Tom Lane wrote:
>> 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).
Well, think about it.
1. Let's say user A owns the pre-existing table and user B owns the
extension. Who owns the index?
2. Generally speaking, if an object is part of an extension then you
can't drop the object without dropping the whole extension. This means
that either user A can't drop his own table, or he can but that causes
dropping the whole extension (which he does not own), not to mention
whatever else depends on it (which he owns even less).
3. Can user A do something that would mutate the index? (For instance,
ALTER COLUMN TYPE on one of the columns it's on.) Now is it still a
member of the extension? If user A can't, can user B? What if either of
them mutated the column to a datatype that belongs to some extension that
has a dependency on the original one? Now you've got a circular
dependency loop, what fun --- especially at dump/reload time, where
pg_dump has no hope of breaking the circularity.
4. If we're going to support indexes as independent members of extensions,
why not foreign-key constraints, or check constraints? Maybe check
constraints on domain types that don't belong to the extension? Heck,
why not allow an extension to do ALTER TABLE ADD COLUMN? (I think
BTW that several of these cases would allow creation of circular
extension dependencies even without any ALTER COLUMN TYPE shenanigans.)
None of this makes any sense, because these things are not stand-alone
objects in any sense of the word. They are attributes of tables (or
domain types, for that case) and there are good reasons why we don't
consider such attributes to have ownership independent of the object
they are part of. I do not think it is sensible for an extension to "own"
objects that don't also have, or could potentially have [1], independent
ownership in the sense of an owning user.
> Imagine you use extensions to break the application into modules.
I do not think that extensions as we currently understand them are a
suitable basis for slicing an application in the way you suggest.
I'm fine with an extension owning a whole table, but the rest of this
is just crazy. And I sure as hell do not want to put it in as part
of a bug fix for existing releases.
regards, tom lane
[1] weasel wording for cases like casts, which we don't consider
to have owners, though I'm not sure why not.
