Re: no test programs in contrib
От | Andres Freund |
---|---|
Тема | Re: no test programs in contrib |
Дата | |
Msg-id | 20141128180102.GE5164@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: no test programs in contrib (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: no test programs in contrib
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: