Re: Finer Extension dependencies - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Finer Extension dependencies
Date
Msg-id 1332512915-sup-7094@alvh.no-ip.org
Whole thread Raw
In response to Re: Finer Extension dependencies  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Finer Extension dependencies  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Excerpts from Dimitri Fontaine's message of vie mar 23 11:05:37 -0300 2012:

>   =# \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.

Hm, couldn't it be done simply with a qsort()?  Presumably there aren't
many feature entries to sort ...

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: checkpoint patches
Next
From: Alvaro Herrera
Date:
Subject: Re: Uppercase tab completion keywords in psql?