Tom Lane <tgl@sss.pgh.pa.us> writes:
> User trust, maybe, but the "maintenance" argument seems bogus.
> We ship contrib on the same release schedule as core.
I meant maintenance as in updating the code when it needs to be, I'm not
sure contrib systematically receives the same careness as core. I have
no data to back my feeling, though.
> TBH, I don't believe that ordinary users will need this tool at all,
> ever, and thus I don't want it in src/bin/. From a packaging standpoint
> it will be a lot easier if it's in contrib ... otherwise I'll probably
> have to invent some new sub-RPM along the lines of postgresql-extras
> so as to avoid bloating the core server package.
Oh. I didn't know that the server package would be considered bloated by
anyone and that would impact the way to ship our binaries.
What about splitting contrib *officially* then, not just in your RH
packages, and have postgresql-server-extra-diagnosis, -extra-data-types
and -contrib with the things you tipically don't want in production?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support