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. 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.
Servus
Manfred
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
