ITAGAKI Takahiro wrote: > Magnus Hagander <[EMAIL PROTECTED]> wrote: > >>> I'd like to submit pg_stat_statements contrib module >> Sounds very good, but why contrib and not along with the rest of the >> stats stuff in the main backend (with an on/off switch if the overhead >> is high)? > > That's because it could be done as a contrib module ;-) > (Yeah! Postgres is a very extensible database!)
It can also go as a pgfoundry project, no? ;-) Given that making it a contrib module instead of core will significantly decrease the exposure, I personally consider that a bad thing.. > I'm not sure what should be in the main and what should not. > Why is pg_freespacemap still in contrib? I don't know, why is it? :-) > I think the module is not mature yet and users will want to > modify it to their satisfaction. It will be easier if the > module is separated from the core codes. (The same can be > said for contrib/auto_explan, which is my other proposal.) Yes, that is a reasonable argument for keeping it in contrib. Or perhaps even better, on pgFoundry until it is ready. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
