pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedplpgsql doesn't coerce boolean expressions to boolean
25+ messages / 9 participants
[nested] [flat]
* plpgsql doesn't coerce boolean expressions to boolean
@ 2003-09-08 15:40 Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:10 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Andrew Dunstan <andrew@dunslane.net>
2003-09-08 16:20 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-09 06:43 ` Re: plpgsql doesn't coerce boolean expressions to boolean R. van Twisk <r.vantwisk@jongert.nl>
2003-09-09 14:56 ` Re: plpgsql doesn't coerce boolean expressions to boolean Manfred Koizar <mkoi-pg@aon.at>
2003-09-09 15:27 ` Re: plpgsql doesn't coerce boolean expressions to boolean Richard Hall <rhall@micropat.com>
2003-09-09 17:14 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-26 22:47 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 7 replies; 25+ messages in thread
From: Tom Lane @ 2003-09-08 15:40 UTC (permalink / raw)
To: pgsql-hackers@postgreSQL.org; pgsql-sql
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
the value if it's not the case. This seems pretty bogus to me.
However ... with the code as it stands, for pass-by-reference datatypes
any nonnull value will appear TRUE, while for pass-by-value datatypes
any nonzero value will appear TRUE. I fear that people may actually be
depending on these behaviors, particularly the latter one which is
pretty reasonable if you're accustomed to C. So while I'd like to throw
an error if the argument isn't boolean, I'm afraid of breaking people's
function definitions.
Here are some possible responses, roughly in order of difficulty
to implement:
1. Leave well enough alone (and perhaps document the behavior).
2. Throw an error if the expression doesn't return boolean.
3. Try to convert nonbooleans to boolean using plpgsql's usual method
for cross-type coercion, ie run the type's output proc to get a
string and feed it to bool's input proc. (This seems unlikely to
avoid throwing an error in very many cases, but it'd be the most
consistent with other parts of plpgsql.)
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.)
Any opinions about what to do?
regards, tom lane
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-08 16:10 ` Andrew Dunstan <andrew@dunslane.net>
6 siblings, 0 replies; 25+ messages in thread
From: Andrew Dunstan @ 2003-09-08 16:10 UTC (permalink / raw)
To: pgsql-hackers@postgresql.org; pgsql-sql
Tom Lane wrote:
>Following up this gripe
>http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
>I've realized that plpgsql just assumes that the test expression
>of an IF, WHILE, or EXIT statement is a boolean expression. It
>doesn't take any measures to ensure this is the case or convert
>the value if it's not the case. This seems pretty bogus to me.
>
>However ... with the code as it stands, for pass-by-reference datatypes
>any nonnull value will appear TRUE, while for pass-by-value datatypes
>any nonzero value will appear TRUE. I fear that people may actually be
>depending on these behaviors, particularly the latter one which is
>pretty reasonable if you're accustomed to C. So while I'd like to throw
>an error if the argument isn't boolean, I'm afraid of breaking people's
>function definitions.
>
>Here are some possible responses, roughly in order of difficulty
>to implement:
>
>1. Leave well enough alone (and perhaps document the behavior).
>
>2. Throw an error if the expression doesn't return boolean.
>
>3. Try to convert nonbooleans to boolean using plpgsql's usual method
> for cross-type coercion, ie run the type's output proc to get a
> string and feed it to bool's input proc. (This seems unlikely to
> avoid throwing an error in very many cases, but it'd be the most
> consistent with other parts of plpgsql.)
>
>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.)
>
>Any opinions about what to do?
>
>
>
It won't bite me so maybe I don't have a right to express an opinion :-)
plpgsql is not C - it appears to be in the Algol/Pascal/Ada family,
which do tend to avoid implicit type conversion.
On that basis, option 2 seems like it might be the right answer and also
the one most likely to break lots of existing functions. Maybe the right
thing would be to deprecate relying on implicit conversion to boolean
for one release cycle and then make it an error.
cheers
andrew
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-08 16:20 ` Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 16:35 ` Re: plpgsql doesn't coerce boolean expressions to boolean Doug McNaught <doug@mcnaught.org>
6 siblings, 1 reply; 25+ messages in thread
From: Andreas Pflug @ 2003-09-08 16:20 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgreSQL.org
Tom Lane wrote:
>Here are some possible responses, roughly in order of difficulty
>to implement:
>
>1. Leave well enough alone (and perhaps document the behavior).
>
>2. Throw an error if the expression doesn't return boolean.
>
I'd opt for 2.
It's quite common that newer compilers will detect more bogus coding
than older ones. There might be existing functions that break from this
because they rely on the current "feature", but there are probably
others that will throw an exception, revealing bad coding (and
delivering correct results just by chance, I've seen this more than once...)
Regards,
Andreas
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:20 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andreas Pflug <pgadmin@pse-consulting.de>
@ 2003-09-08 16:35 ` Doug McNaught <doug@mcnaught.org>
2003-09-08 16:47 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 25+ messages in thread
From: Doug McNaught @ 2003-09-08 16:35 UTC (permalink / raw)
To: Andreas Pflug <pgadmin@pse-consulting.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers@postgresql.org
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Tom Lane wrote:
>
> >
> >2. Throw an error if the expression doesn't return boolean.
> >
> I'd opt for 2.
> It's quite common that newer compilers will detect more bogus coding
> than older ones. There might be existing functions that break from
> this because they rely on the current "feature", but there are
> probably others that will throw an exception, revealing bad coding
> (and delivering correct results just by chance, I've seen this more
> than once...)
I agree, and option 2 also makes sure that "bad" code will fail
cleanly, rather than possibly changing behavior and causing data
loss/corruption.
I agree with another poster that deprecation in 7.4 and removal in
7.5 might make sense.
-Doug
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:20 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 16:35 ` Re: plpgsql doesn't coerce boolean expressions to boolean Doug McNaught <doug@mcnaught.org>
@ 2003-09-08 16:47 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:56 ` Re: plpgsql doesn't coerce boolean expressions to boolean Doug McNaught <doug@mcnaught.org>
2003-09-08 16:57 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 18:27 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andrew Dunstan <andrew@dunslane.net>
0 siblings, 3 replies; 25+ messages in thread
From: Tom Lane @ 2003-09-08 16:47 UTC (permalink / raw)
To: Doug McNaught <doug@mcnaught.org>; +Cc: Andreas Pflug <pgadmin@pse-consulting.de>; pgsql-hackers@postgresql.org
Doug McNaught <doug@mcnaught.org> writes:
> I agree with another poster that deprecation in 7.4 and removal in
> 7.5 might make sense.
How would we "deprecate" it exactly? Throw a NOTICE?
regards, tom lane
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:20 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 16:35 ` Re: plpgsql doesn't coerce boolean expressions to boolean Doug McNaught <doug@mcnaught.org>
2003-09-08 16:47 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-08 16:56 ` Doug McNaught <doug@mcnaught.org>
2 siblings, 0 replies; 25+ messages in thread
From: Doug McNaught @ 2003-09-08 16:56 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andreas Pflug <pgadmin@pse-consulting.de>; pgsql-hackers@postgresql.org
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Doug McNaught <doug@mcnaught.org> writes:
> > I agree with another poster that deprecation in 7.4 and removal in
> > 7.5 might make sense.
>
> How would we "deprecate" it exactly? Throw a NOTICE?
I was thinking of just a mention in the release notes that we've found
this problem and intend to fix it after giving people a release cycle
to adjust. Not that people read release notes... :(
-Doug
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:20 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 16:35 ` Re: plpgsql doesn't coerce boolean expressions to boolean Doug McNaught <doug@mcnaught.org>
2003-09-08 16:47 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-08 16:57 ` Andreas Pflug <pgadmin@pse-consulting.de>
2 siblings, 0 replies; 25+ messages in thread
From: Andreas Pflug @ 2003-09-08 16:57 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Doug McNaught <doug@mcnaught.org>; pgsql-hackers@postgresql.org
Tom Lane wrote:
>Doug McNaught <doug@mcnaught.org> writes:
>
>
>>I agree with another poster that deprecation in 7.4 and removal in
>>7.5 might make sense.
>>
>>
>
>How would we "deprecate" it exactly? Throw a NOTICE?
>
Good question. A NOTICE just might be ignored, breaking everything
"surprisingly" in 7.5.
To speak a bit more general, how about some sort of "deprecation
checker" setting, if set to true anything marked as deprecated will
throw an error, if false only a notice will be generated. This would
enable users to check their existing stuff for future compatibility
before it's broken in the next release.
Regards,
Andreas
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:20 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 16:35 ` Re: plpgsql doesn't coerce boolean expressions to boolean Doug McNaught <doug@mcnaught.org>
2003-09-08 16:47 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-08 18:27 ` Andrew Dunstan <andrew@dunslane.net>
2003-09-08 20:28 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 25+ messages in thread
From: Andrew Dunstan @ 2003-09-08 18:27 UTC (permalink / raw)
To: Postgresql Hackers <pgsql-hackers@postgresql.org>
Tom Lane wrote:
>Doug McNaught <doug@mcnaught.org> writes:
>
>
>>I agree with another poster that deprecation in 7.4 and removal in
>>7.5 might make sense.
>>
>>
>
>How would we "deprecate" it exactly? Throw a NOTICE?
>
>
>
Release notes, I guess. A NOTICE would be fine as long as it didn't
result in a flood of them. If that happened once at parse time that
should be fine, I think.
What's the practice in deprecating other "features"?
cheers
andrew
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:20 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 16:35 ` Re: plpgsql doesn't coerce boolean expressions to boolean Doug McNaught <doug@mcnaught.org>
2003-09-08 16:47 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 18:27 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andrew Dunstan <andrew@dunslane.net>
@ 2003-09-08 20:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 21:31 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 25+ messages in thread
From: Tom Lane @ 2003-09-08 20:28 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Postgresql Hackers <pgsql-hackers@postgresql.org>
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> How would we "deprecate" it exactly? Throw a NOTICE?
>>
> Release notes, I guess. A NOTICE would be fine as long as it didn't
> result in a flood of them. If that happened once at parse time that
> should be fine, I think.
It would be relatively difficult to do that; given the way plpgsql is
structured, a runtime message would be a lot easier.
> What's the practice in deprecating other "features"?
We generally don't ;-). Certainly 7.4 contains bigger incompatible
changes than this one, and so have most of our prior releases.
regards, tom lane
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:20 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 16:35 ` Re: plpgsql doesn't coerce boolean expressions to boolean Doug McNaught <doug@mcnaught.org>
2003-09-08 16:47 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 18:27 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andrew Dunstan <andrew@dunslane.net>
2003-09-08 20:28 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-08 21:31 ` Andrew Dunstan <andrew@dunslane.net>
0 siblings, 0 replies; 25+ messages in thread
From: Andrew Dunstan @ 2003-09-08 21:31 UTC (permalink / raw)
To: Postgresql Hackers <pgsql-hackers@postgresql.org>
Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>What's the practice in deprecating other "features"?
>>
>>
>
>We generally don't ;-). Certainly 7.4 contains bigger incompatible
>changes than this one, and so have most of our prior releases.
>
>
>
I thought I had seen discussions along the lines of "we'll give them one
cycle to fix it and then they are shot".
It does seem very late in this cycle to make such changes.
cheers
andrew
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-09 06:43 ` R. van Twisk <r.vantwisk@jongert.nl>
6 siblings, 0 replies; 25+ messages in thread
From: R. van Twisk @ 2003-09-09 06:43 UTC (permalink / raw)
To: 'Tom Lane' <tgl@sss.pgh.pa.us>; pgsql-hackers@postgresql.org; pgsql-sql
I would suggest to throw a error, or at least a warning.
This will FORCE people to program in the correct way.
I also thought that 'IF $1 THEN ...' should work ok but giving it a other
thought it's indeed stuped to write that way (I'm from the C world...)
Ries
-----Oorspronkelijk bericht-----
Van: pgsql-sql-owner@postgresql.org
[mailto:pgsql-sql-owner@postgresql.org]Namens Tom Lane
Verzonden: maandag 8 september 2003 17:41
Aan: pgsql-hackers@postgresql.org; pgsql-sql@postgresql.org
Onderwerp: [SQL] plpgsql doesn't coerce boolean expressions to boolean
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
the value if it's not the case. This seems pretty bogus to me.
However ... with the code as it stands, for pass-by-reference datatypes
any nonnull value will appear TRUE, while for pass-by-value datatypes
any nonzero value will appear TRUE. I fear that people may actually be
depending on these behaviors, particularly the latter one which is
pretty reasonable if you're accustomed to C. So while I'd like to throw
an error if the argument isn't boolean, I'm afraid of breaking people's
function definitions.
Here are some possible responses, roughly in order of difficulty
to implement:
1. Leave well enough alone (and perhaps document the behavior).
2. Throw an error if the expression doesn't return boolean.
3. Try to convert nonbooleans to boolean using plpgsql's usual method
for cross-type coercion, ie run the type's output proc to get a
string and feed it to bool's input proc. (This seems unlikely to
avoid throwing an error in very many cases, but it'd be the most
consistent with other parts of plpgsql.)
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.)
Any opinions about what to do?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-09 14:56 ` Manfred Koizar <mkoi-pg@aon.at>
2003-09-09 15:54 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 1 reply; 25+ messages in thread
From: Manfred Koizar @ 2003-09-09 14:56 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org; pgsql-sql
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.
Servus
Manfred
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 14:56 ` Re: plpgsql doesn't coerce boolean expressions to boolean Manfred Koizar <mkoi-pg@aon.at>
@ 2003-09-09 15:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:57 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 25+ messages in thread
From: Tom Lane @ 2003-09-09 15:54 UTC (permalink / raw)
To: Manfred Koizar <mkoi-pg@aon.at>; +Cc: pgsql-hackers@postgresql.org; pgsql-sql
Manfred Koizar <mkoi-pg@aon.at> writes:
> 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.
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
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 14:56 ` Re: plpgsql doesn't coerce boolean expressions to boolean Manfred Koizar <mkoi-pg@aon.at>
2003-09-09 15:54 ` Re: plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-09 17:57 ` Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 25+ messages in thread
From: Bruce Momjian @ 2003-09-09 17:57 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Manfred Koizar <mkoi-pg@aon.at>; pgsql-hackers@postgresql.org; pgsql-sql
Tom Lane wrote:
> Manfred Koizar <mkoi-pg@aon.at> writes:
> > 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.
>
> I'm willing to do that.
OK, what release should we do this?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-09 15:27 ` Richard Hall <rhall@micropat.com>
6 siblings, 0 replies; 25+ messages in thread
From: Richard Hall @ 2003-09-09 15:27 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org; pgsql-sql
Define the language! If it breaks code, so be it.
2. Throw an error if the expression doesn't return boolean.
Yes, yes, absolutely.
By definition "an IF, WHILE, or EXIT statement is a boolean expression"
SO
if "some stupid piece of text" THEN
should not compile, there is no BOOLEAN expression.
C's implementation of hat is true and false has always, IMHO, been hideous.
But then again, I am a Pascal kind of thinker.
An integer with a value of 1 is still only an integer,
IF I <> 0 THEN ...
is clear and un-ambiguous.
Tom Lane wrote:
> Following up this gripe
> http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
> I've realized that plpgsql just assumes that the test expression
> of an IF, WHILE, or EXIT statement is a boolean expression. It
> doesn't take any measures to ensure this is the case or convert
> the value if it's not the case. This seems pretty bogus to me.
>
> However ... with the code as it stands, for pass-by-reference datatypes
> any nonnull value will appear TRUE, while for pass-by-value datatypes
> any nonzero value will appear TRUE. I fear that people may actually be
> depending on these behaviors, particularly the latter one which is
> pretty reasonable if you're accustomed to C. So while I'd like to throw
> an error if the argument isn't boolean, I'm afraid of breaking people's
> function definitions.
>
> Here are some possible responses, roughly in order of difficulty
> to implement:
>
> 1. Leave well enough alone (and perhaps document the behavior).
>
> 2. Throw an error if the expression doesn't return boolean.
>
> 3. Try to convert nonbooleans to boolean using plpgsql's usual method
> for cross-type coercion, ie run the type's output proc to get a
> string and feed it to bool's input proc. (This seems unlikely to
> avoid throwing an error in very many cases, but it'd be the most
> consistent with other parts of plpgsql.)
>
> 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.)
>
> Any opinions about what to do?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-09 17:14 ` Jan Wieck <JanWieck@Yahoo.com>
2003-09-09 17:32 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 1 reply; 25+ messages in thread
From: Jan Wieck @ 2003-09-09 17:14 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org; pgsql-sql
Tom Lane wrote:
> Following up this gripe
> http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
> I've realized that plpgsql just assumes that the test expression
> of an IF, WHILE, or EXIT statement is a boolean expression. It
> doesn't take any measures to ensure this is the case or convert
> the value if it's not the case. This seems pretty bogus to me.
>
> However ... with the code as it stands, for pass-by-reference datatypes
> any nonnull value will appear TRUE, while for pass-by-value datatypes
> any nonzero value will appear TRUE. I fear that people may actually be
> depending on these behaviors, particularly the latter one which is
> pretty reasonable if you're accustomed to C. So while I'd like to throw
> an error if the argument isn't boolean, I'm afraid of breaking people's
> function definitions.
>
> Here are some possible responses, roughly in order of difficulty
> to implement:
>
> 1. Leave well enough alone (and perhaps document the behavior).
>
> 2. Throw an error if the expression doesn't return boolean.
ERROR is the cleanest way, but I'd vote for conversion to boolean to
keep the damage within reason.
Jan
>
> 3. Try to convert nonbooleans to boolean using plpgsql's usual method
> for cross-type coercion, ie run the type's output proc to get a
> string and feed it to bool's input proc. (This seems unlikely to
> avoid throwing an error in very many cases, but it'd be the most
> consistent with other parts of plpgsql.)
>
> 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.)
>
> Any opinions about what to do?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:14 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
@ 2003-09-09 17:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:51 ` Re: plpgsql doesn't coerce boolean expressions to boolean Andrew Dunstan <andrew@dunslane.net>
2003-09-10 01:56 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
0 siblings, 2 replies; 25+ messages in thread
From: Tom Lane @ 2003-09-09 17:32 UTC (permalink / raw)
To: Jan Wieck <JanWieck@Yahoo.com>; +Cc: pgsql-hackers@postgresql.org; pgsql-sql
Jan Wieck <JanWieck@Yahoo.com> writes:
> ERROR is the cleanest way, but I'd vote for conversion to boolean to
> keep the damage within reason.
Which style of conversion did you like? These were the choices:
>> 3. Try to convert nonbooleans to boolean using plpgsql's usual method
>> for cross-type coercion, ie run the type's output proc to get a
>> string and feed it to bool's input proc. (This seems unlikely to
>> avoid throwing an error in very many cases, but it'd be the most
>> consistent with other parts of plpgsql.)
>>
>> 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.)
At this point I'm kinda leaning to #4, because (for example) people
could create a cast from integer to boolean to avoid having to fix their
plpgsql functions right away. #3 would not offer any configurability of
behavior.
regards, tom lane
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:14 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-09 17:32 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-09 17:51 ` Andrew Dunstan <andrew@dunslane.net>
1 sibling, 0 replies; 25+ messages in thread
From: Andrew Dunstan @ 2003-09-09 17:51 UTC (permalink / raw)
To: Postgresql Hackers <pgsql-hackers@postgresql.org>
Tom Lane 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.)
>>>
>>>
>
>At this point I'm kinda leaning to #4, because (for example) people
>could create a cast from integer to boolean to avoid having to fix their
>plpgsql functions right away. #3 would not offer any configurability of
>behavior.
>
>
>
Won't people have to analyse their functions to find out what sort of
casts they need to create? If so, why don't they just fix the functions
while they are about it? Surely the fixes in most cases will be quite
trivial, and in all cases backwards compatible.
Does anyone have a take on how many people would be affected? Or how
much they would be affected?
cheers
andrew
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:14 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-09 17:32 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-10 01:56 ` Jan Wieck <JanWieck@Yahoo.com>
2003-09-28 01:28 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 25+ messages in thread
From: Jan Wieck @ 2003-09-10 01:56 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jan Wieck <JanWieck@Yahoo.com>; pgsql-hackers@postgresql.org; pgsql-sql
Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> ERROR is the cleanest way, but I'd vote for conversion to boolean to
>> keep the damage within reason.
>
> Which style of conversion did you like? These were the choices:
>
>>> 3. Try to convert nonbooleans to boolean using plpgsql's usual method
>>> for cross-type coercion, ie run the type's output proc to get a
>>> string and feed it to bool's input proc. (This seems unlikely to
>>> avoid throwing an error in very many cases, but it'd be the most
>>> consistent with other parts of plpgsql.)
>>>
>>> 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.)
>
> At this point I'm kinda leaning to #4, because (for example) people
> could create a cast from integer to boolean to avoid having to fix their
> plpgsql functions right away. #3 would not offer any configurability of
> behavior.
Agreed - #4.
Thinking of the problem about deprication of features and transition
time, it would be nice for this kind of compatibility breaking changes
to have a _per database_ config option that controls old vs. new
behaviour, wouldn't it? Don't know exactly how you'd like that to be.
Maybe with a pg_config catalog that inherits default settings from
template1 but can then be changed in every database. This would even
include the possibility to *switch* one single prod database back to the
old behaviour in case the supposedly cleaned up application isn't as
clean as supposed to.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:14 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-09 17:32 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-10 01:56 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
@ 2003-09-28 01:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-28 03:33 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to Jan Wieck <JanWieck@Yahoo.com>
0 siblings, 1 reply; 25+ messages in thread
From: Tom Lane @ 2003-09-28 01:28 UTC (permalink / raw)
To: Jan Wieck <JanWieck@Yahoo.com>; +Cc: pgsql-hackers@postgresql.org
Jan Wieck <JanWieck@Yahoo.com> writes:
> Tom Lane 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.)
> Agreed - #4.
My first attempt at doing this failed to pass the regression tests,
because it wasn't prepared for this:
if count(*) = 0 from Room where roomno = new.roomno then
raise exception ''Room % does not exist'', new.roomno;
end if;
Is this really intended to be a feature? It manages to work because
plpgsql simply sticks "SELECT " in front of whatever appears between
IF and THEN, and passes the result to the main SQL engine. But it sure
surprised the heck out of me. The documentation gives no hint that
you're allowed to write anything but a straight boolean expression in IF.
Does Oracle allow that sort of thing?
I would be inclined to think that a more reasonable expression of the
intent would be
if (select count(*) from Room where roomno = new.roomno) = 0 then
Certainly we'd have a big problem supporting the existing coding if we
ever reimplement plpgsql with more awareness of what expressions are.
regards, tom lane
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [SQL] plpgsql doesn't coerce boolean expressions to
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:14 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-09 17:32 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-10 01:56 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-28 01:28 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-28 03:33 ` Jan Wieck <JanWieck@Yahoo.com>
2003-09-28 16:02 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 25+ messages in thread
From: Jan Wieck @ 2003-09-28 03:33 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jan Wieck <JanWieck@Yahoo.com>; pgsql-hackers@postgresql.org
Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> Tom Lane 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.)
>
>> Agreed - #4.
>
> My first attempt at doing this failed to pass the regression tests,
> because it wasn't prepared for this:
>
> if count(*) = 0 from Room where roomno = new.roomno then
> raise exception ''Room % does not exist'', new.roomno;
> end if;
>
> Is this really intended to be a feature? It manages to work because
> plpgsql simply sticks "SELECT " in front of whatever appears between
> IF and THEN, and passes the result to the main SQL engine. But it sure
> surprised the heck out of me. The documentation gives no hint that
> you're allowed to write anything but a straight boolean expression in IF.
> Does Oracle allow that sort of thing?
I have to admit it was less an intention than more a side effect of the
actual implementation. It was so easy to simply stick "SELECT " in front
of "everything between IF and THEN" and expect the result to be a boolean.
In the same way you can do
varname := count(*) from Room where roomno = new.roomno;
which is straight forward because it's simply sticking "SELECT " in
front of "everything between := and ;". Well, this does a bit more in
that it tries the typinput(typoutput(result)) casting hack ... I know
that you don't like that one.
>
> I would be inclined to think that a more reasonable expression of the
> intent would be
>
> if (select count(*) from Room where roomno = new.roomno) = 0 then
>
> Certainly we'd have a big problem supporting the existing coding if we
> ever reimplement plpgsql with more awareness of what expressions are.
Without parsing much, much more, and finally parsing basically the whole
SQL grammar in the PL/pgSQL parser, I don't see how you can do that.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [SQL] plpgsql doesn't coerce boolean expressions to
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:14 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-09 17:32 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-10 01:56 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-28 01:28 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-28 03:33 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to Jan Wieck <JanWieck@Yahoo.com>
@ 2003-09-28 16:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-30 22:26 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 25+ messages in thread
From: Tom Lane @ 2003-09-28 16:02 UTC (permalink / raw)
To: Jan Wieck <JanWieck@Yahoo.com>; +Cc: pgsql-hackers@postgresql.org
Jan Wieck <JanWieck@Yahoo.com> writes:
> Tom Lane wrote:
>> if count(*) = 0 from Room where roomno = new.roomno then
>> raise exception ''Room % does not exist'', new.roomno;
>> end if;
>>
>> Is this really intended to be a feature?
> I have to admit it was less an intention than more a side effect of the
> actual implementation. It was so easy to simply stick "SELECT " in front
> of "everything between IF and THEN" and expect the result to be a boolean.
Sure, it was easy given a certain implementation technique. Question
is, do we want to consider it a supported feature even if it makes the
implementation hard?
> In the same way you can do
> varname := count(*) from Room where roomno = new.roomno;
This actually doesn't bother me; I see it as simply a variant syntax
for SELECT INTO. (Perhaps it should be documented that way.)
If we want to preserve this behavior for IF et al, I don't think there
is any practical way to apply SQL-level type coercion as I had wanted.
We could instead make the code act like it's assigning to a plpgsql
boolean variable --- but it will apply plpgsql's textual conversion
methods, not SQL type coercion.
regards, tom lane
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [SQL] plpgsql doesn't coerce boolean expressions to
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:14 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-09 17:32 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-10 01:56 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Jan Wieck <JanWieck@Yahoo.com>
2003-09-28 01:28 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-28 03:33 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to Jan Wieck <JanWieck@Yahoo.com>
2003-09-28 16:02 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-30 22:26 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 25+ messages in thread
From: Tom Lane @ 2003-09-30 22:26 UTC (permalink / raw)
To: Jan Wieck <JanWieck@Yahoo.com>; +Cc: pgsql-hackers@postgresql.org
I said:
> If we want to preserve this behavior for IF et al, I don't think there
> is any practical way to apply SQL-level type coercion as I had wanted.
> We could instead make the code act like it's assigning to a plpgsql
> boolean variable --- but it will apply plpgsql's textual conversion
> methods, not SQL type coercion.
I have now written and tested the patch for this --- it's doing what I
originally called option 3:
>>> 3. Try to convert nonbooleans to boolean using plpgsql's usual method
>>> for cross-type coercion, ie run the type's output proc to get a
>>> string and feed it to bool's input proc. (This seems unlikely to
>>> avoid throwing an error in very many cases, but it'd be the most
>>> consistent with other parts of plpgsql.)
Unless someone objects, I'll commit this.
regards, tom lane
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-09-26 22:47 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-26 22:53 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
6 siblings, 1 reply; 25+ messages in thread
From: Bruce Momjian @ 2003-09-26 22:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org; pgsql-sql
Where are we on this --- we all decided on #4. Does this just require
an announcment in the release notes.
(I need to complete the release notes soon.)
---------------------------------------------------------------------------
Tom Lane wrote:
> Following up this gripe
> http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
> I've realized that plpgsql just assumes that the test expression
> of an IF, WHILE, or EXIT statement is a boolean expression. It
> doesn't take any measures to ensure this is the case or convert
> the value if it's not the case. This seems pretty bogus to me.
>
> However ... with the code as it stands, for pass-by-reference datatypes
> any nonnull value will appear TRUE, while for pass-by-value datatypes
> any nonzero value will appear TRUE. I fear that people may actually be
> depending on these behaviors, particularly the latter one which is
> pretty reasonable if you're accustomed to C. So while I'd like to throw
> an error if the argument isn't boolean, I'm afraid of breaking people's
> function definitions.
>
> Here are some possible responses, roughly in order of difficulty
> to implement:
>
> 1. Leave well enough alone (and perhaps document the behavior).
>
> 2. Throw an error if the expression doesn't return boolean.
>
> 3. Try to convert nonbooleans to boolean using plpgsql's usual method
> for cross-type coercion, ie run the type's output proc to get a
> string and feed it to bool's input proc. (This seems unlikely to
> avoid throwing an error in very many cases, but it'd be the most
> consistent with other parts of plpgsql.)
>
> 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.)
>
> Any opinions about what to do?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 25+ messages in thread
* Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-26 22:47 ` Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-09-26 22:53 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 25+ messages in thread
From: Tom Lane @ 2003-09-26 22:53 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: pgsql-hackers@postgresql.org; pgsql-sql
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Where are we on this --- we all decided on #4. Does this just require
> an announcment in the release notes.
I haven't done anything about it --- been busy with other stuff, and I
wasn't sure we'd agreed to change it for 7.4 anyway. I'm willing to
make the code change though.
regards, tom lane
^ permalink raw reply [nested|flat] 25+ messages in thread
end of thread, other threads:[~2003-09-30 22:26 UTC | newest]
Thread overview: 25+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-09-08 15:40 plpgsql doesn't coerce boolean expressions to boolean Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:10 ` Andrew Dunstan <andrew@dunslane.net>
2003-09-08 16:20 ` Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 16:35 ` Doug McNaught <doug@mcnaught.org>
2003-09-08 16:47 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 16:56 ` Doug McNaught <doug@mcnaught.org>
2003-09-08 16:57 ` Andreas Pflug <pgadmin@pse-consulting.de>
2003-09-08 18:27 ` Andrew Dunstan <andrew@dunslane.net>
2003-09-08 20:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-08 21:31 ` Andrew Dunstan <andrew@dunslane.net>
2003-09-09 06:43 ` R. van Twisk <r.vantwisk@jongert.nl>
2003-09-09 14:56 ` Manfred Koizar <mkoi-pg@aon.at>
2003-09-09 15:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:57 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-09 15:27 ` Richard Hall <rhall@micropat.com>
2003-09-09 17:14 ` Jan Wieck <JanWieck@Yahoo.com>
2003-09-09 17:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-09 17:51 ` Andrew Dunstan <andrew@dunslane.net>
2003-09-10 01:56 ` Jan Wieck <JanWieck@Yahoo.com>
2003-09-28 01:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-09-28 03:33 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to Jan Wieck <JanWieck@Yahoo.com>
2003-09-28 16:02 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to Tom Lane <tgl@sss.pgh.pa.us>
2003-09-30 22:26 ` Re: [SQL] plpgsql doesn't coerce boolean expressions to Tom Lane <tgl@sss.pgh.pa.us>
2003-09-26 22:47 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-09-26 22:53 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox