From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: plpgsql doesn't coerce boolean expressions to boolean |
Date: | 2003-09-09 14:56:20 |
Message-ID: | 2uorlv41aahh6fp3773r5pkjdnm26m4cc5@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
On Mon, 08 Sep 2003 11:40:32 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2003-09-09 14:56:52 | Re: Maximum table size |
Previous Message | Gaetano Mendola | 2003-09-09 14:53:06 | Re: [PATCHES] mcxt.c |
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Hall | 2003-09-09 15:27:24 | Re: plpgsql doesn't coerce boolean expressions to boolean |
Previous Message | scott.marlowe | 2003-09-09 13:13:56 | Re: undefine currval() |