Re: Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader
Date
Msg-id m27goodwya.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: pg_dump cosmetic problem while dumping/restoring rules
Next
From: Peter Geoghegan
Date:
Subject: Re: Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader