Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
От | Jan Wieck |
---|---|
Тема | Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean |
Дата | |
Msg-id | 3F5E84CF.6090706@Yahoo.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 #
В списке pgsql-sql по дате отправления: