> > In the comment for patch 0021 you write that the function casting type > circle to type polygon cannot be error safe, because it's a SQL > language function. I suggest to convert this to a C function and make > the required changes there. >
> About the main feature patch: I'm not a fan of the CREATE CAST > ... WITH SAFE FUNCTION syntax. First, the CREATE CAST syntax is part > of the SQL standard. It would be weird if we needed a nonstandard > syntax to make two standard features work together. Second, we didn't > do this when we introduced error-safe type input functions. There is > a note on the CREATE TYPE man page that use of ereturn() is > encouraged, and then we left it to extension authors to do the right > thing. (And we should now put a similar note on the CREATE CAST man > page.) And third, requiring this would require a lot of churn in all > affected extensions, requiring new extension SQL files and forcing > upgrades. The changes you did in patch 0023 don't do this correctly, > for example. This leaves us in a tricky situation if we can't tell ahead of time if a cast function really can handle soft errors. We could just allow any and all (CAST ... ON ERROR) calls even if the casting function can't actually return soft errors. That's unfortunate, but it might be the simplest and best way forward given that the alternative is to raise an error at planner time guaranteeing a query failure when the values presented might not have triggered the conversion errors. > Tactical suggestion: Add an SQL-callable function, say, > pg_cast_conversion_succeeds(srcvalue, desttype) that checks whether > the cast would succeed. This would be similar to the > pg_input_is_valid() function that we added to test the type input > functions. (I did not call my proposal pg_cast_is_valid() because > that might indicate merely that a casting path exists.) With that, > the higher-level functionality can be constructed by hand (CASE WHEN > pg_cast_conversion_succeeds(...) THEN CAST(...) ELSE 'default value' > END). And then we can later work on building out the higher-level > functionality and make more cast functions error safe. You're describing the the "x IS CASTABLE AS y" syntax proposed in the same standards proposal document :)
