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

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Дата
Msg-id CADkLM=eTwrU-fA4K--9jDsfRe0OYV_qKGxXvoor3AEJVUnBWEQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)  ("Daniel Verite" <daniel@manitou-mail.org>)
Ответы Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)  (Corey Huinker <corey.huinker@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
ISTM that it's important that eventually ParseVariableBool()
and \if agree on what evaluates to true and false (and the
more straightforward way to achieve that is by \if calling
directly ParseVariableBool), but that it's not productive that we
discuss /if issues relatively to the behavior of ParseVariableBool()
in HEAD at the moment, as it's likely to change.

I'd like to keep in sync with ParseVariableBoolean(), but 

Also, Fabien has made a good case for invalid parsed values being an ON_ERROR_STOP-able error, and not defaulted to either true or false.

This might be asking a lot, but could we make a "strict" mode for ParseVariableBool() that returns a success boolean, and have the existing ParseVariableBool() signature call that new function, and issue the "assuming " warning if the strict function failed?


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..
Следующее
От: Tobias Oberstein
Дата:
Сообщение: Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..