On 5 June 2012 23:55, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Plus. if we have extensions, why does adding a function need to force >> an initdb?? Why don't we use our own infrastructure? > > I thought I already pointed that out, but: we have *extensions*. What > we don't have is a convenient method of dealing with functions that need > to be migrated across extensions, or from an extension to core, between > one major release and the next. It would clearly be nice to have that > someday, but we don't have it now. Designing on the assumption that 9.3 > will be able to do that nicely, when the required infrastructure is > still barely at the handwaving stage, seems like folly to me. > > (In fact, pg_upgrade has more or less broken the ability even to do > significant refactoring within an extension, as I was ranting about in > another thread recently. We really need to fix that. But let's not > assume it's going to happen on any particular schedule.)
What I had in mind was adding a final step to initdb that registers a few "system extensions". We then make the default way to add functions to Postgres is to create a system extension in src/backend/extensions/xxx, not a hard-assigned oid function via pg_proc. As far as the worlds knows the functions added in this way would be part of default postgres. Called in a predictable sequence they would have the same oids on all platforms. It would be fairly simple to drop all existing "system extensions" then re-add them again, as part of the beta upgrade process. And much simpler to produce patches that add functions. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers