Re: libpq URI and regression testing
| От | Andrew Dunstan |
|---|---|
| Тема | Re: libpq URI and regression testing |
| Дата | |
| Msg-id | 4F8DBE96.5080601@dunslane.net обсуждение исходный текст |
| Ответ на | Re: libpq URI and regression testing (Alvaro Herrera <alvherre@commandprompt.com>) |
| Ответы |
Re: libpq URI and regression testing
Re: libpq URI and regression testing |
| Список | pgsql-hackers |
On 04/17/2012 02:47 PM, Alvaro Herrera wrote: > Excerpts from Peter Eisentraut's message of mar abr 17 15:41:04 -0300 2012: >> On tis, 2012-04-17 at 10:47 -0300, Alvaro Herrera wrote: >>> What's the preferred way to make it automatically tested as much as >>> possible? I know the buildfarm does not run "installcheck-world", so if >>> we want it there, it'd need a bit more code on the client side. I think >>> it would be wise to have it also run on installcheck-world. >> It was agreed during the patch discussion that it shouldn't be run >> automatically. > Oh, okay. I didn't notice that. I guess we should issue a > call-for-testing, then, so that we ensure it works (FSVO works) in all > (FSVO all) platforms. > >>> Hmm. Just had this thought: not all platform support the same socket >>> types. Maybe we should have separated the .in file in three parts: >>> IPv4, IPv6, unix-domain socket. That way each platform would only run >>> tests that pertain to it. Right now there's a single "regress.in" file >>> that lists all the tests. >> That's one reason for that, but there are probably others in the way of >> making this fully portable and automatable. This test setup also appears to labor under the illusion that we live in a Unix-only world. And for no good reason that I can tell. The shell script should be ripped out and replaced by a perl script which could actually be used on any windows build host. The MSVC build system also needs adjusting to make it build the test driver, at least. cheers andrew
В списке pgsql-hackers по дате отправления: