Re: Finer Extension dependencies - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Finer Extension dependencies
Date
Msg-id 87d383pg3y.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Finer Extension dependencies  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Finer Extension dependencies
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Alvaro Herrera <alvherre@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.

Please find v5 of the patch attached, where

  =# \d pg_extension_feature
  Table "pg_catalog.pg_extension_feature"
     Column   | Type | Modifiers
  ------------+------+-----------
   extoid     | oid  | not null
   extfeature | name | not null
  Indexes:
      "pg_extension_feature_name_index" UNIQUE, btree (extfeature)
      "pg_extension_feature_oid_index" UNIQUE, btree (oid)
      "pg_extension_feature_extoid_name_index" btree (extoid, extfeature)

We could maybe get rid of the (extoid, extfeature) index which is only
used to get sorted output in list_extension_features() function, but I
don't know how to do an ORDER BY scan without index in C (yet).

The ordering is then used to maintain pg_depend when the list of
provided features changes at upgrade time. We fetch the ordered list of
“old” feature names then for each newly provided feature name we
bsearch() the old list, which then needs to be properly ordered.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Unnecessary WAL archiving after failover
Next
From: Stephen Frost
Date:
Subject: Re: checkpoint patches