Re: Failure with regression test largeobject if pg_regress invoked from external paths
От | Tom Lane |
---|---|
Тема | Re: Failure with regression test largeobject if pg_regress invoked from external paths |
Дата | |
Msg-id | 5512.1452050944@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Failure with regression test largeobject if pg_regress invoked from external paths (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Failure with regression test largeobject if pg_regress
invoked from external paths
|
Список | pgsql-bugs |
Michael Paquier <michael.paquier@gmail.com> writes: > On Wed, Jan 6, 2016 at 11:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Um ... what exactly is the triggering condition here? > Perhaps my previous email was not clear enough. Attached is a small > script that emulates what my colleague infrastructure is doing on a > running instance. I see; so the point is you haven't cd'ed into src/test/regress. I'm not sure if that's a case we ought to support or not. In particular, it's pretty unclear what is the benefit of this script compared to "make -C $PG_SRC/src/test/regress check". The script certainly will break anytime we change the set of arguments the Makefile passes to pg_regress, which we have done before and no doubt will do again. Again, I don't see much harm in the patch you propose, it's more a question of should we contract to support this use-case. It's not zero cost to do so; we might for example be able to get rid of some (in/out)put/*.source files if we didn't need to substitute @abs_builddir@ in them. Those things are a PITA to maintain, too, so I'm not very eager to add on more reasons why tests would need them. regards, tom lane
В списке pgsql-bugs по дате отправления: