On 2014-11-27 15:51:51 -0500, Tom Lane wrote:
> Josh Berkus <josh@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
