Thread: Feature Matrix
All,
(1) can we update the 9.0b2 column to read 9.0?
(2) contrib/intarray is listed as obsolete as of 8.3. Huh? How does
that work? I'm still using it ...
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On 9 August 2010 00:42, Josh Berkus <josh@agliodbs.com> wrote: > All, > > (1) can we update the 9.0b2 column to read 9.0? > > (2) contrib/intarray is listed as obsolete as of 8.3. Huh? How does > that work? I'm still using it ... > The matrix is also beginning to look a bit busy too. Once support for 7.4 and 8.0 stops, do you think we should also drop those columns? If so, we could also drop rows where a feature exists from 8.1 or before which would trim the list. -- Thom Brown Registered Linux user: #516935
> The matrix is also beginning to look a bit busy too. Once support for
> 7.4 and 8.0 stops, do you think we should also drop those columns?
Yes, I think so. At least 7.4.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
Thom Brown wrote: > The matrix is also beginning to look a bit busy too. Once support for > 7.4 and 8.0 stops, do you think we should also drop those columns? If > so, we could also drop rows where a feature exists from 8.1 or before > which would trim the list. > I think it would be nice to save the existing content to somewhere before doing that trimming through. Having a chart showing the major feature evolution of the database that goes back as far as possible is really useful sometimes. Perhaps forking the current chart into a "7.4 through 9.0" history, and then trimming everything from before 8.1 before adding a 9.1 column? -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
2010/8/11 Greg Smith <greg@2ndquadrant.com>: > Thom Brown wrote: >> >> The matrix is also beginning to look a bit busy too. Once support for >> 7.4 and 8.0 stops, do you think we should also drop those columns? If >> so, we could also drop rows where a feature exists from 8.1 or before >> which would trim the list. >> > > I think it would be nice to save the existing content to somewhere before > doing that trimming through. Having a chart showing the major feature > evolution of the database that goes back as far as possible is really useful > sometimes. Perhaps forking the current chart into a "7.4 through 9.0" > history, and then trimming everything from before 8.1 before adding a 9.1 > column? > +1 Pavel Stehule > -- > Greg Smith 2ndQuadrant US Baltimore, MD > PostgreSQL Training, Services and Support > greg@2ndQuadrant.com www.2ndQuadrant.us > > > -- > Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-advocacy >
On 11 August 2010 01:29, Greg Smith <greg@2ndquadrant.com> wrote: > Thom Brown wrote: >> >> The matrix is also beginning to look a bit busy too. Once support for >> 7.4 and 8.0 stops, do you think we should also drop those columns? If >> so, we could also drop rows where a feature exists from 8.1 or before >> which would trim the list. >> > > I think it would be nice to save the existing content to somewhere before > doing that trimming through. Having a chart showing the major feature > evolution of the database that goes back as far as possible is really useful > sometimes. Perhaps forking the current chart into a "7.4 through 9.0" > history, and then trimming everything from before 8.1 before adding a 9.1 > column? > +1 Sounds good to me. :) -- Thom Brown Registered Linux user: #516935
On 08/11/2010 02:29 AM, Greg Smith wrote: > Thom Brown wrote: >> The matrix is also beginning to look a bit busy too. Once support for >> 7.4 and 8.0 stops, do you think we should also drop those columns? If >> so, we could also drop rows where a feature exists from 8.1 or before >> which would trim the list. > > I think it would be nice to save the existing content to somewhere > before doing that trimming through. Having a chart showing the major > feature evolution of the database that goes back as far as possible is > really useful sometimes. Perhaps forking the current chart into a "7.4 > through 9.0" history, and then trimming everything from before 8.1 > before adding a 9.1 column? well there are some plans on making the matrix more dynamic with the new website - but for now I think just hiding the 7.4 and maybe 8.0 columns will do. Stefan
On 08/09/2010 01:42 AM, Josh Berkus wrote: > All, > > (1) can we update the 9.0b2 column to read 9.0? 9.0 is not yet released and the list is only synced up to Beta2 - I was planning to give the site a full overhaul once we are up to RC1(as said earlier on -www - because we kept adding new stuff even during the betas) and the release notes are more or less done (so that the wording there and in the FM is similiar) > (2) contrib/intarray is listed as obsolete as of 8.3. Huh? How does > that work? I'm still using it ... hmm not sure about that - maybe some c&p error but I don't know how that happened. Should be fixed with the next site update anyway. Stefan
> hmm not sure about that - maybe some c&p error but I don't know how that
> happened. Should be fixed with the next site update anyway.
I think that you mixed it up with array_agg, which is obsolete as of 8.4.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On 11 August 2010 18:57, Josh Berkus <josh@agliodbs.com> wrote: > >> hmm not sure about that - maybe some c&p error but I don't know how that >> happened. Should be fixed with the next site update anyway. > > I think that you mixed it up with array_agg, which is obsolete as of 8.4. > Eh? I thought array_agg was only introduced in 8.4? -- Thom Brown Registered Linux user: #516935