Tom Lane <t...@sss.pgh.pa.us> writes: >> That's how I did it first, but Alvaro opposed to that because it allows >> for more than one extension to provide for the same feature name. >> http://archives.postgresql.org/pgsql-hackers/2012-03/msg01425.php > > Right, but the question that has to be considered is how often would > that be intentional as opposed to an undesirable name collision. > I think Hitoshi was right upthread that it will seldom if ever be > the case that somebody is independently reimplementing somebody > else's API, so the use-case for intentional substitution seems thin.
I reverted that change and we're now back to:
Table "pg_catalog.pg_extension_feature"
Column | Type | Modifiers
------------+------+-----------
extoid | oid | not null
extfeature | name | not null
Indexes:
"pg_extension_feature_index" UNIQUE, btree (extoid, extfeature)
"pg_extension_feature_oid_index" UNIQUE, btree (oid)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
extension-provides.v7.patch.gz
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
