Re: Quick Extensions Question
От | Robert Haas |
---|---|
Тема | Re: Quick Extensions Question |
Дата | |
Msg-id | AANLkTikuSY4RRi0jwJ=9JW3Gx9rQKBgNTRe7Mbcwgmb5@mail.gmail.com обсуждение исходный текст |
Ответ на | Quick Extensions Question ("David E. Wheeler" <david@kineticode.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: