Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Дата
Msg-id alpine.DEB.2.20.1703120825100.5791@lancre
обсуждение исходный текст
Ответ на Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Starting to poke at this... the proposal to add prove checks for psql 
> just to see whether \if respects ON_ERROR_STOP seems like an incredibly 
> expensive way to test a rather minor point. On my machine, "make check" 
> in bin/psql goes from zero time to close to 8 seconds.  I'm not really 
> on board with adding that kind of time to every buildfarm run for the 
> foreseeable future just for this.

ISTM that these tests allowed to find bugs in the implementation, so they 
were useful at some point. They are still useful in the short term if the 
implementation is to be changed significantly to respond to your various 
requirements. The underlying issue with TAP test is that it installs a new 
cluster on each script, which is quite costly.

In this case, the same result could be achieved with a number of small 
failing tests, which only launch "psql". Could that be acceptable? What 
you suggest is to keep only *one* failing test, which I find is kind of a 
regression from a testing coverage perspective, although obviously it is 
possible.

-- 
Fabien.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] scram and \password
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)