ITAGAKI Takahiro wrote:
> Magnus Hagander <magnus@hagander.net> 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