Dimitri Fontaine <dimi...@2ndquadrant.fr> writes: > ... My fix is > to have deleteDependencyRecordsFor use true for skipExtensionDeps.
On further reflection, there's some merit in that fix too. The question is what do we think should happen if the pre-existing shell operator belongs to another extension. It seems like the reasonable alternatives are (1) delete those pg_depend entries and allow the current extension to take ownership. (2) throw an error. What you suggest above would result in (2), whereas what I was thinking of would result in (1). The case where this would actually happen is where extension A creates some operator, and mentions some other operator as its commutator or negator, but never gets around to defining the other operator. Then extension B comes along and tries to fill in the other operator definition. Do we want to let that happen, or do we want to throw an error on the grounds that this sort of interconnection of two extensions was almost certainly not intended? (Note that I rather doubt that dropping either extension alone, afterwards, would clean up nicely, since we have no code that would remove the oprcom/oprnegate linkage.) A completely different line of thought is that maybe extension membership records shouldn't be created at all for a shell operator, on the grounds that it's not a real object but only a placeholder until it's filled in. One somewhat analogous situation is where we create a shell type and then fill it in later. That code uses skipExtensionDeps = true and so will end up throwing an error if the pre-existing membership is for another extension. However, it's pretty hard to imagine a useful situation where an extension would create a shell type and not fill it in, so I'm not sure that this is a close analogy. On the whole I'm starting to think that throwing an error is the best thing. We could always relax that later, but going the other way might be problematic. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs