Alvaro Herrera <alvhe...@commandprompt.com> writes: > Hmm .. feature names should be globally unique, right? If so I think > you're missing an UNIQUE index on the new catalog, covering just the > feature name. You have a two column index (extoid, featurename), so you > could have two different extensions providing the same feature. Is this > okay? If it is, then there is a bit of a bogus code in
You're right, this looks like something I forgot to go back to, the unique index should be global on the feature's name. I will go make that happen (tomorrow). > I noticed that you've left unspecified whether an extension should have > a "provides" entry for itself or not -- I mean the code adds one if it's > not there. I'm not sure about this, maybe it's okay. But this makes it > impossible for it to say "provides: extname-0.5" and have a dependent > extension fail if it only requires "extname", because that one will be > provided automatically whether extname's author wants it or not. > Again, maybe this is okay. I think it is ok, at least that's how I intended the feature to work. The use case I want to allow is for the other extension's author to say its extension depends on the extname-0.5 feature. In fact I guess that you would rather provide feature names, not version, so as not to have to look up a feature matrix each time. For the use case you're concerned with, I think that if an extension's upgrade is not compatible with the previous version, the extension name itself should be changed (extname2 or extname-1.0 or whatever). Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers