Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean
Дата
Msg-id 2uorlv41aahh6fp3773r5pkjdnm26m4cc5@email.aon.at
обсуждение исходный текст
Ответ на plpgsql doesn't coerce boolean expressions to boolean  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, 08 Sep 2003 11:40:32 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>4. Use the parser's coerce_to_boolean procedure, so that nonbooleans
>   will be accepted in exactly the same cases where they'd be accepted
>   in a boolean-requiring SQL construct (such as CASE).  (By default,
>   none are, so this isn't really different from #2.  But people could
>   create casts to boolean to override this behavior in a controlled
>   fashion.)

I vote for 4.  And - being fully aware of similar proposals having
failed miserably - I propose to proceed as follows:

If the current behaviour is considered a bug, let i=4, else let i=5.

In 7.i:  Create a new GUC variable "plpgsql_strict_boolean" (silly
name, I know) in the "VERSION/PLATFORM COMPATIBILITY" section of
postgresql.conf.  Make the new behaviour dependent on this variable.
Default plpgsql_strict_boolean to false.  Place a warning into the
release notes and maybe into the plpgsql documentation.

In 7.j, j>i:  Change the default value of plpgsql_strict_boolean to
true.  Issue WARNINGs or NOTICEs as appropriate.  Update
documentation.

In 7.k, k>j:  Remove old behaviour and GUC variable.  Update
documentation.

ServusManfred


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [PATCHES] mcxt.c
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean