Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
От | Tom Lane |
---|---|
Тема | Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless) |
Дата | |
Msg-id | 24980.1490748720@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) (Corey Huinker <corey.huinker@gmail.com>) |
Список | pgsql-hackers |
Corey Huinker <corey.huinker@gmail.com> writes: [ 0001-psql-if-v28.patch ] Starting to look at this version, and what jumped out at me in testing is that the regression output looks like this: parallel group (12 tests): psql_if_on_error_stop dbsize async misc_functions tidscan alter_operator tsrf psql alter_genericmisc stats_ext sysviews alter_generic ... ok alter_operator ... ok misc ... ok psql ... ok psql_if_on_error_stop ... ok (test process exited with exitcode 3) async ... ok dbsize ... ok misc_functions ... ok sysviews ... ok tsrf ... ok tidscan ... ok stats_ext ... ok Don't think we can have that. Even if pg_regress considers it a success, every hacker is going to have to learn that that's a "pass", and I don't think I want to be answering that question every week till kingdom come. I'm not really sure we need a test for this behavior. If we're sufficiently dead set on it, we could go back to the TAP-based approach, but I still doubt that this test is worth the amount of overhead that would add. regards, tom lane
В списке pgsql-hackers по дате отправления: