Re: Oid registry
От | Dimitri Fontaine |
---|---|
Тема | Re: Oid registry |
Дата | |
Msg-id | m2haql7u84.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: Oid registry (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > Andrew Dunstan <andrew@dunslane.net> writes: >> Given your previous comments, perhaps we could just start handing out >> Oids (if there is any demand) numbered, say, 9000 and up. That should >> keep us well clear of any existing use. > > No, I think you missed my point entirely: handing out OIDs at the top > of the manual assignment range is approximately the worst possible > scenario. I foresee having to someday move FirstBootstrapObjectId If that's the only problem, there's an easy way out by registering from the top of the Oid range down to some constant up over there. Now it seems like the problem here is that we both want the extension to be managed as disconnected as possible from PostgreSQL, and at the same time we want to be able to trust them from within the backend with it being the only trusted authority. I'm not security oriented enough to devise a working scheme here, but it makes me think about some "shared secret" or GnuPG signature. Is it possible to automatically verify that an extension's ID card (containing some type's OID, name, etc) has been signed with PostgreSQL's own private key, without ever having to ship that key in the backend code nor binary? To me it's all about how to setup a distributed network of trust… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: