You are happily casting 1 and 0 to boolean in the SELECT statements, and then grumbling when not casting them in the INSERT statements. So is there a reason to forbid 0 and 1 as valid boolean, without explicit cast ? ![]() This behavior cannot be changed, as this cast is hard coded with "Implicit?=no".Īnd added to this weirdness is the fact that '1' or '0' (with quote) is OK. HINT: You will need to rewrite or cast the expression. Why the default is to throw an error when casting Integer to Boolean in assignment, and accepting it everywhere else ?īut you *cannot* use 1 or 0 as valid input for boolean type when inserting or updating :ĮRROR: column "a" is of type boolean but expression is of type integer Maybe this question has been debated before (I didn't find anything helpful) but : On 1/24/19 5:04 AM, Alexandre GRAIL wrote: When I install the system to solve this for my own uses. OR (src.typname ILIKE 'bit%' AND tgt.typname ILIKE '%int') OR (src.typname ILIKE 'bit%' AND tgt.typname ILIKE 'bool%') OR (src.typname ILIKE 'bool%' AND tgt.typname ILIKE 'bit%') OR (src.typname ILIKE 'bool%' AND tgt.typname ILIKE '%int%') WHERE (src.typname ILIKE '%int%' AND tgt.typname ILIKE 'bool%') Inner join pg_type tgt ON tgt.oid = c.casttarget Inner join pg_type src ON src.oid = c.castsource ![]() UPDATE pg_cast SET castcontext = 'i' WHERE oid IN ( ![]() My own opinion is that non-0 should implicitly cast as true and 0 There's additional text describing why casts are chosen to be defined The reason for that at least is that '1' and '0' are valid boolean values. And added to this weirdness is the fact that '1' or '0' (with quote) is OK.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |