Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers