Re: Oid registry

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oid registry
Date: 2012-09-26 15:37:32
Message-ID: m2r4po23sz.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-09-26 16:04:34 Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)
Previous Message Tomas Vondra 2012-09-26 15:35:02 Re: autovacuum stress-testing our system