On 5 June 2012 23:55, Tom Lane <tgl@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