On 2014-11-27 15:51:51 -0500, Tom Lane wrote: > Josh Berkus <j...@agliodbs.com> writes: > > So test_decoding is fairly useful for users demonstrating that decoding > > works, especially if they're also testing an external decoding module > > and are unsure of where their replication problem is located, or what's > > wrong with their HBA settings. For that reason it's important that > > test_decoding be available via OS packages, which would give me some > > reluctance to move it out of /contrib. > > If we follow that reasoning we'll end up removing nothing from contrib. > There is no reason that end users should need to be performing such > testing; anyone who does have reason to do it will have a source tree > at hand.
Actually I don't think that's true for test_decoding - there's quite a bit of actual things that you can do with it. At the very least it's useful to roughly measure the impact logical replication would have on a database, but it's also helpful to look at the changes. And even if the format isn't super nice, thanks to Robert's insistence it's actually safely parseable if necessary. > > dummy_seclabel might serve the same purpose for users who are having > > issues with SEPostgres etc. I don't know enough about it ... > > And as for dummy_seclabel, the same applies in spades, considering > that the number of users of SEPostgres can probably be counted without > running out of fingers. I agree that dummy_seclabel really doesn't have any applications besides regression tests. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers