Re: contrib loose ends: 9.0 to 9.1 incompatibilities - Mailing list pgsql-hackers

On Wed, Feb 16, 2011 at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm.  Can we just invent a way to hook them from the opclasses?  I
>> have a feeling that now that this extension stuff is in we're going to
>> discover a bunch of these little utility commands that we managed to
>> get by without in the past but now that we're getting more organized
>> about it, we'll need 'em.
>
> Maybe so.  My thought is that extension update scripts are going to be
> executed in very well-defined circumstances and it might not be so bad
> to let them do direct UPDATEs on the system catalogs instead of writing
> lots of special-purpose ALTER commands.  In the particular case here,
> unhooking, deleting, recreating, and rehooking the functions seems like
> way more trouble than it's worth.

The trouble is that we have no mechanism for conditional logic in
upgrade scripts, so if the system catalog structure should change in a
way that causes the hook and unhook mechanism to require different
logic depending on which PG major version is in use, we're hosed.  Or
at the very least third-party extension authors are hosed.  While I
have to hold my nose every time I think about the architecture of
pg_upgrade, one thing that it does do for us is provide a significant
degree of insulation against problems caused by system catalog
changes.

Ultimately, the effect of being unable to change on disk format,
system catalogs, or other aspects of the system between version is
that important and valuable improvements get shot down on
compatibility grounds.  Inventing mechanisms that protect us from that
is important.  I invented the extensible EXPLAIN-options syntax not so
much because I wanted to be able to get XML output out of it as
because I figured that, once we had a way of adding options without
fighting with the syntax, people who weren't me would figure out what
those options should be and add them.  And so it proved: EXPLAIN
(BUFFERS) is a very nice feature, much more useful to me personally
than EXPLAIN (FORMAT), and I think eventually we'll have more.

I don't feel that bad about releasing 9.1 without this
unhook-and-rehook machinery because I think we've done pretty well to
get this feature as far as we have, and at this point I'm definitely
in the camp of wanting a release sooner rather than wanting to squeeze
more stuff into it.  Having said that, these kinds of problems are
impossible to correct without pain if you wait until you're actually
backed against the wall.  Push will come to shove when someone wants
to change the system catalog representation in a way that makes the
UPDATE commands used for previous releases no longer work.  At that
point, regardless of whether you add the unhook-and-rehook mechanism
or whether you just modify the UPDATE commands to work with the new
structure, you've now imposed a minimum major PG version requirement
on that extension that is otherwise unnecessary, or else you now have
to distribute two different versions of the extension based on
associated major PG release.  If we add the unhook-and-rehook
mechanism in 9.2, there's a good chance that by the time we need it, a
few releases will have gone by and no great pain will result.  If not,
then at some point there will be a flag day.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company