Excerpts from Dimitri Fontaine's message of vie mar 23 12:26:47 -0300 2012:
>
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > 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 ...
>
> Mmmm… Then we would need an index on extoid to be able to list features
> of a given extension, and that would be the only usage of such an index.
> I guess that having it include the feature's name is not so expensive as
> to try avoiding it and qsort() in the code rather than scan the index in
> order?
Well, as far as I can see the only use of
pg_extension_feature_extoid_name_index right now is the same as the only
use for the extoid index. I mean, what you really want is to find out
the features of an extension, right? The extfeature column is just
there to provide you with the ordering, which should be easy to
determine outside of the index.
Why do features have OIDs? Is this for pg_depend entries? If so, would
it work to have pg_depend entries point to extensions instead?
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
