Re: Oid registry - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Oid registry
Date
Msg-id m2r4po23sz.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Oid registry  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Here is a problem:  If I write an "hstore-ng" extension, I have two

In the patch for Finer Extension Dependencies, the offer is that you
have the hstore-ng extension provide the 'hstore' feature.
 https://commitfest.postgresql.org/action/patch_view?id=727

Now, that says nothing about the type's OID nor how to trust it.

In my proposal we would have a pg_features catalog, that are just
keywords used in control files so that you can change your mind as far
as dependencies are concerned from one release of your extension to the
next (adding or removing some, splitting the extension in parts or
joining them again, etc).

Those features entries do not exist yet, and are a very specific set of
OIDs, so we could maybe provision a large number of them here and refuse
to assign them to untrusted sources.

Again, the complex part of that problem, to me, is not about how to
manage those numbers (running a registry, adding syntax support, etc) as
much as how to manage a distributed network of trust.

When applying for an OID or a feature identifier, the registry team
could maybe GPG sign "something" with the PostgreSQL private key, the
backend only having the public key embedded in its code and binary. IIRC
that's enough to then validate the feature name/oid (with the signature,
a new control file parameter) and allow it to get installed in the
registry reserved range.

We then need a way to ask for the list of objects provided by the
extension providing that feature (it's been signed, it's now trusted),
something that we already know how to do (joining pg_depend etc). The
result of that query would be cached on the client side, because we're
not trying to change the way pg_type OID assignment ranges work. We
could maybe specialize all this down to pg_type and distribute a list of
reserved OIDs there too, but it seems like that ship has already sailed
(nice pg_upgrade chicken and egg problem).

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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: autovacuum stress-testing our system
Next
From: Alvaro Herrera
Date:
Subject: Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)