Re: Finer Extension dependencies

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Finer Extension dependencies
Date: 2012-03-23 15:45:30
Message-ID: 1332516992-sup-945@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Excerpts from Dimitri Fontaine's message of vie mar 23 12:26:47 -0300 2012:
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-03-23 15:49:18 Re: query cache
Previous Message Tom Lane 2012-03-23 15:36:49 Re: [COMMITTERS] pgsql: Add notion of a "transform function" that can simplify function