Re: Quick Extensions Question - Mailing list pgsql-hackers

On Thu, Mar 3, 2011 at 11:39 AM, Aidan Van Dyk <aidan@highrise.ca> wrote:
> No, what is being talked about isn't intended as a "way of installing
> languages that is ... nicer".  What is being talked about is allowing
> an "Extension" that is being installed know that it's going to blow up
> because it's required language (plpgsql, for instance) isn't
> installed.
>
> Maybe it's a problem with extensions that isn't easily solvable, but
> that means extension authors are going to have a readme in their
> extension with the followign text:
>   EXTENSION "mystuff" requires that pl/pgsql be installed in the
>   database.  There is no way for the extension to check this before
>   it is installed, so make sure it's installed, or be prepared to
>   cope with errors during the installation.
>
>   And make sure you don't try and drop pl/pgsql language when
>   the extension is installed either.
>
>
> Maybe that's enough for 9.1.

Well, in 9.0, what'll happen is you'll type psql -f somefile.sql and
it'll spit out a stream of error messages if things aren't in the
prerequisite state.  Unless you happen to have taken the precaution of
wrapping the whole thing in a transaction, you may end up with the
extension half-installed and some fun manual cleanup to do.  I'm not
going to argue that this is perfect, but it is already better than it
was.  The extensions patch didn't change much between mid-Decemeber
when we wrapped up CF#3 and early February when Tom picked it up.  If
he wanted to have a chance to do lots more refinement after the
initial commit, he had the means within his grasp: he could have
picked it up in December.  It is no more fair for Tom to hold up this
release to work on extensions than it is for Simon to hold it up to
work on sync rep.  Jeff Davis would have loved to get range types in,
Alvaro would have liked to do finish his work on foreign key locks,
and there are other examples as well.  We can't expect anyone to be
willing to step aside graciously when time has expired unless everyone
is willing to do it.

By the way, I don't question Tom's decision to leave this patch until
February.  He worked on other things.  Who am I to say that they were
any less valuable than this?  But you can't have your cake and eat it
too.  There's a part of me that wonders whether we'd get the same
number of features per release if we shortened the release cycle by
one CommitFest.  Most large patches get done in 2 or 3 CommitFests, so
it would still be entirely reasonable to get a major feature done in
one release.  Right now we seem to have two classes of people: the
ones who start working at the beginning of the cycle, and are done by
CF#2/#3, and the ones who start at the end of the cycle, and hold
things up at the end.  Neither group would get any less done on a
shorter cycle.  Contrariwise I bet if we went to 5 CommitFests we'd
see only a slight increase in patches - they'd just be spread out over
more calendar time.  It's already the case that the middle two
CommitFests are smaller than the first and last.

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