Tom Lane writes:
Personally I find the extension stuff to be a bigger deal than anything
else remaining in the commitfest. Also, I've fixed a number of
pre-existing bugs in passing, and I'd have to go extract those changes
out of the current extensions patch if we abandon it now. So I'd like
to keep pushing ahead on this.
Personally I find the extension stuff to be a bigger deal than anything
else remaining in the commitfest. Also, I've fixed a number of
pre-existing bugs in passing, and I'd have to go extract those changes
out of the current extensions patch if we abandon it now. So I'd like
to keep pushing ahead on this.
much time as I did already to assist as much as I can here.
After further reflection I think that the pg_upgrade situation can be
handled like this:
1. Provide a way for CREATE EXTENSION to not run the script --- either
add a grammar option for that, or just have a back-door flag that
pg_upgrade can set via one of its special kluge functions. (Hm,
actually we'd want it to install the old version number and comment
too, so maybe just have a kluge function to create a pg_extension
entry that agrees with the old entry.)
In the upgrade patch there's provision for not running the script:handled like this:
1. Provide a way for CREATE EXTENSION to not run the script --- either
add a grammar option for that, or just have a back-door flag that
pg_upgrade can set via one of its special kluge functions. (Hm,
actually we'd want it to install the old version number and comment
too, so maybe just have a kluge function to create a pg_extension
entry that agrees with the old entry.)
CREATE WRAPPER EXTENSION foo;
That's pretty useful indeed. What it does now is read the control file
to init the comment and other fields, but extversion is forced NULL.
That allows to have special rules in how UPGRADE will pick a script.
There's even code to do
CREATE WRAPPER EXTENSION foo WITH SYSID 12345;
We could add version and comment here for purposes of pg_upgrade.
2. Invent a command "ALTER EXTENSION extname ADD object-description"
that simply adds a pg_depend entry marking an existing object as
belonging to the extension. I think this was going to be part of the
plan anyway for ALTER EXTENSION UPGRADE, specifically we need that for
the bootstrap case of collecting some loose pre-existing objects into
an extension.
In the upgrade patch, that's spelled ALTER OBJECT foo SET EXTENSION bar;that simply adds a pg_depend entry marking an existing object as
belonging to the extension. I think this was going to be part of the
plan anyway for ALTER EXTENSION UPGRADE, specifically we need that for
the bootstrap case of collecting some loose pre-existing objects into
an extension.
and does exactly what you're proposing.
3. In --binary-upgrade mode, pg_dump doesn't suppress the individual
member objects, but instead emits ALTER EXTENSION ADD after creating
each member object.
So that gets us to the point of being able to run pg_upgrade without
changing the contents of the extension. After that we can look at
ALTER EXTENSION UPGRADE.
Well, or begin there as the code you need is already written.member objects, but instead emits ALTER EXTENSION ADD after creating
each member object.
So that gets us to the point of being able to run pg_upgrade without
changing the contents of the extension. After that we can look at
ALTER EXTENSION UPGRADE.
Regards,
