Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean |
Дата | |
Msg-id | 200309262247.h8QMllm12659@candle.pha.pa.us обсуждение исходный текст |
Ответ на | plpgsql doesn't coerce boolean expressions to boolean (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
|
Список | 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, Pennsylvania19073
В списке pgsql-sql по дате отправления: