Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Mon, 08 Sep 2003 11:40:32 -0400, Tom Lane <[EMAIL PROTECTED]>
> 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.
I'm willing to do that.
> 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.
I'm not willing to do that much work for what is, in the greater scheme
of things, a tiny change. If we did that for every user-visible change,
our rate of forward progress would be a mere fraction of what it is.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
