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