Alexandre GRAIL wrote: > On 24/01/2019 12:45, Geoff Winkless wrote: > > My own opinion is that non-0 should implicitly cast as true and 0 > > should cast as false. I just run > > > > UPDATE pg_cast SET castcontext = 'i' WHERE oid IN ( > > SELECT c.oid > > FROM pg_cast c > > inner join pg_type src ON src.oid = c.castsource > > inner join pg_type tgt ON tgt.oid = c.casttarget > > WHERE (src.typname ILIKE '%int%' AND tgt.typname ILIKE 'bool%') > > OR (src.typname ILIKE 'bool%' AND tgt.typname ILIKE '%int%') > > OR (src.typname ILIKE 'bool%' AND tgt.typname ILIKE 'bit%') > > OR (src.typname ILIKE 'bit%' AND tgt.typname ILIKE 'bool%') > > OR (src.typname ILIKE 'bit%' AND tgt.typname ILIKE '%int') > > ); > > Thanks Geoff for this solution, I was thinking it cannot be changed ! I > end up doing this : > > UPDATE pg_cast SET castcontext = 'a' WHERE oid IN ( > SELECT c.oid > FROM pg_cast c > inner join pg_type src ON src.oid = c.castsource > inner join pg_type tgt ON tgt.oid = c.casttarget > WHERE (src.typname ILIKE '%int%' AND tgt.typname ILIKE 'bool%') > ); > > Only to have 0/1 => bool working in assignment. It saved me from > injecting ALTER TYPE before and after any INSERT/UPDATE. > > In my case I don't control the query which is auto generated. (And the > framework assumes 1 and 0 are safe boolean values without cast or quote. > Changing that is not possible.) You are aware that catalog modifications are not supported, right? One of the reasons is that these modifications will be gone after a major upgrade, and you'll have to remember to re-apply them. Making type casts more liberal increases the risk of ambiguities during type resolution, which cause error messages if PostgreSQL cannot find a single best candidate. So there is a price you are paying - but if it works for you, you probably won't mind. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
