Re: Why not install pgstattuple by default?
От | Greg Smith |
---|---|
Тема | Re: Why not install pgstattuple by default? |
Дата | |
Msg-id | 4DC86D37.7060902@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Why not install pgstattuple by default? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Why not install pgstattuple by default?
|
Список | pgsql-hackers |
On 05/09/2011 02:31 PM, Robert Haas wrote: > I don't think we should be too obstinate about trying to twist the arm > of packagers who (as Tom points out) will do whatever they want in > spite of us, but the current state of contrib, with all sorts of > things of varying type, complexity, and value mixed together cannot > possibly be a good thing. I think the idea I'm running with for now means that packagers won't actually have to do anything. I'd expect typical packaging for 9.1 to include share/postgresql/extension from the build results without being more specific. You need to grab 3 files from there to get the plpgsql extension, and I can't imagine any packager listing them all by name. So if I dump the converted contrib extensions to put files under there, and remove them from the contrib build area destination, I suspect they will magically jump from the contrib to the extensions area of the server package at next package build; no packager level changes required. The more I look at this, the less obtrusive of a change it seems to be. Only people who will really notice are users who discover more in the basic server package, and of course committers with backporting to do. Since packaged builds of 9.1 current with beta1 seem to be in short supply still, this theory looks hard to prove just yet. I'm very excited that it's packaging week here however (rolls eyes), so I'll check it myself. I'll incorporate the suggestions made since I posted that test patch and do a bigger round of this next, end to end with an RPM set as the output. It sounds like everyone who has a strong opinion on what this change might look like has sketched a similar looking bikeshed. Once a reasonable implementation is hammered out, I'd rather jump to the big argument between not liking change vs. the advocacy benefits to PostgreSQL of doing this; they are considerable in my mind. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
В списке pgsql-hackers по дате отправления: