Re: TAP test module - PostgresClient
| От | Craig Ringer |
|---|---|
| Тема | Re: TAP test module - PostgresClient |
| Дата | |
| Msg-id | CAMsr+YH+RJ=VcdOGy3jJDXmepHXsHN_t4LADODxDrTddgZZnUg@mail.gmail.com обсуждение исходный текст |
| Ответ на | TAP test module - PostgresClient (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
| Ответы |
Re: TAP test module - PostgresClient
(Tom Lane <tgl@sss.pgh.pa.us>)
|
| Список | pgsql-hackers |
On 28 December 2017 at 16:31, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
Hello.
It would be useful if we have interactive sessions for TAP
tests. My first attempt was apparently unstable one that was
using psql.
https://www.postgresql.org/message-id/20170720.152533. 252230418.horiguchi.kyotaro@ lab.ntt.co.jp
Finally the test for the patch in the thread made not need such a
machinery but it is still potentially useful.
I found that there's already a implementation of Perl client but
I saw it was GPL.
If you mean
then it says
"The GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version, or
The "Artistic License" which comes with Perl."
IOW, it's under the Perl license. These are the exact same terms as used by Perl its self:
so I don't think there's any need for hesitation in using it.
But... I wonder if time is better spent figuring out what's wrong with IPC::Run on Win32 so we can use psql properly. That way we don't start writing a new test-only client, and we expand our psql coverage too.
One thing that'd help a lot, IMO, would be teaching psql how to offer a better batch mode interface, where you can clearly determine:
- end of resultset
- start and end of error msg
- end of query (psql has reported any errors and results and is ready for a new query)
I'm sure this would offer benefits well beyond testing, too, given the number of pretty hairy scripts I've seen with psql and 'expect' etc.
Another option might be to teach the TAP infrastructure and the buildfarm client how to fetch cpanminus and build DBD::Pg against our build-tree, so we could use Perl DBI. I know prior discussions of relying on DBI and DBD::Pg have stalled on arguments that we shouldn't require buildfarm admins and especially random people running the test suite to install and maintain them. But if we teach the test suite how to build and run them scoped to the current Pg build using PERL5LIB, users wouldn't *have* to. Internet access could be a sticking point for some, but the same would be true of using something like PgPP unless we bundled it in the Pg tree.
В списке pgsql-hackers по дате отправления: