From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: no test programs in contrib |
Date: | 2014-11-27 20:51:51 |
Message-ID: | 15708.1417121511@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)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.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-11-27 22:26:49 | Re: no test programs in contrib |
Previous Message | Josh Berkus | 2014-11-27 20:47:46 | Re: no test programs in contrib |