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 по дате отправления: