On Sep 24, 2011, at 22:54, Albretch Mueller <lbrt...@gmail.com> wrote: > Do you see any usefulness in such a project? > ~ > Do you know of such a project? Anyone interested? Any suggestions to > someone embarking in it? > ~ > It would be great if PG developers see any good in it and do it themselves ;-) > ~ > lbrtchx >
I can't tell if you mean this as a humorous post of if you just having something in your eye ;-) I cannot imagine you would benefit that much by removing these capabilities compared to simply ignoring them. As a developer I still have to deal with dates and arrays so while PostgreSQL could do less the work still has to be done. I happier having a group of programmers more skilled than myself doing it instead of me. Plus, by having it in the DB I avoid considerable considerable overhead and can now use those features within my SQL statements/queries. I can see where adding complexity could weigh into a do/ignore decision but once it's in and tested why would you want to remove a feature? If it had serious performance implications maybe, but even then arguing for a runtime enable/disable flag would be best so everyone could decide based upon their unique circumstances. Not a project developer but unless and until you can identify meaningful areas of performance degradation you are simply guessing that in simply being feature rich PostgreSQL has sub-optimal performance; but if most/all of the overhead is in areas that you deem critical/core then nothing you would do would have a meaningful impact; and improving the core areas would improve not only your own situation but the core project as well. "Premature optimization is the root of all evil." (someone not me) David J.
