Re: [SQL] [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Bruce Momjian <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [SQL] [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
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 [EMAIL PROTECTED]) > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [SQL] [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> 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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [SQL] [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Jan Wieck <[EMAIL PROTECTED]> 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 ---(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
Re: [SQL] [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
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 [EMAIL PROTECTED]) -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
