Hitoshi Harada <umi.tan...@gmail.com> writes: >>> "pg_extension_feature_index" UNIQUE, btree (extoid, extfeature) > Do you mean you want UNIQUE constraint by this index? I found the > usage is to search feature by (only) its name, so I wondered if extoid > is not necessary.
I guess you're right and that's something I've just left when I should have cleaned it. We need to find which extension is providing which feature, and we need feature names to be globally unique. I'll remove extoid from this index in the next revision on the patch. I'm not in a position to provide that next revision just now, that would happen before the end of the week though. > I guess if we spend more time, we'll figure out what is "feature" > actually, and then will see what kind of columns/attributes are needed > to represent it. Although I agree we can add them later, again, this > may imply the design is premature. (it's ok if i am the only person > who thinks so) You might be right that a feature is more than just a unique name but as things are, that's their only useful property. >>> - What happens if DROP EXTENSION ... CASCADE? Does it work? >> >> It should, what happens when you try? :) > > I just tried DROP EXTENSION now, and found it broken :( > > db1=# create extension kmeans; > CREATE EXTENSION > db1=# drop extension kmeans; > ERROR: cannot drop extension kmeans because extension feature kmeans > requires it > HINT: You can drop extension feature kmeans instead. Can you provide me the test case you've been using? That looks like a bug I need to fix, indeed (unless the problem lies in the test case, which would mean I need to tighten things some more). 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
