| 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: | Whole Thread | Raw Message | 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 |