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=dMgyNQhJw8YV6RT83hJeWcqFuUCe6e3TYnhDNraW+47w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
On Tue, Jan 24, 2017 at 1:15 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

1: unrecognized value "whatever" for "\if"; assuming "on"

I do not think that the script should continue with such an assumption.

I agree, and this means we can't use ParseVariableBool() as-is. I already broke out argument reading to it's own function, knowing that it'd be the stub for expressions. So I guess we start that now. What subset of true-ish values do you think we should support? If we think that real expressions are possible soon, we could only allow 'true' and 'false' for now, but if we expect that expressions might not make it into v10, then perhaps we should support the same text values that coerce to booleans on the server side.

Hmmm. I would text value that coerce to true? I would also accept non-zero integers (eg SELECT 1::BOOL; -- t).


The docs (doc/src/sgml/datatype.sgml) list TRUE 't' 'true' 'y' 'yes' 'on' '1'    vs FALSE 'f' 'false' 'n' 'no' 'off' '0'

However, src/test/regress/expected/boolean.out shows that there's some flexiblity there with spaces, even before you inspect parse_bool_with_len() in src/backend/utils/adt/bool.c.

If we could bring src/backend/utils/adt/bool.c across the server/client wall, I would just use parse_bool_with_len as-is.

As it is, given that whatever I do is temporary until real expressions come into place, that wouldn't be a terrible amount of code copying, and we'd still have a proto-expression that probably isn't going to conflict with whatever expression syntax we do chose. Having said that, if anyone can see ANY reason that some subset of the existing bool-friendly strings would cause a problem with the expression syntax we do hope to use, speak now and we can restrict the accepted values.


I would suggest to assume false on everything else, and/or maybe to ignore the whole if/endif section in such cases.

+1, it also halves the number of values we have to support later. 
 
ISTM that with TAP test you can check for error returns, so maybe this can be done.

I'll have to educate myself on TAP tests.

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] pg_hba_file_settings view patch
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] Protect syscache from bloating with negative cacheentries