Open chaas opened 1 year ago
chaas
commented
1 year ago @benesch resuscitating your old discussion on SQL errors and turning it into an actionable epic/evergreen task. I am planning to move forward now with declaring the postgres standard as our own and applying it to the unknown type error.
I'd like your take on a broader refactor.
cc @ggnall
benesch
commented
1 year ago Thanks for digging that up, Cara! I totally forgot I’d written that up years ago.
The good news is the big refactor of the SQL and coordinator layers came to pass! The structured enum errors do exist. What’s remaining is a very, very long road to stamping out every usage of anyhow::Error and replacing it with a properly structured error. IMO what remains is an essentially an evergreen project to improve each error message one by one. I’m very supportive of a big push to fix the next ten, twenty, fifty, whatever of these error messages, though I think each of the fixes can be a small focused PR. Is that what you had in mind?
chaas
commented
1 year ago Yeah we still default to using the !sql_err macro in a lot of places, which creates a PlanError::Unstructured, which is technically not a anyhow::Error, but still is essentially just a single error string. Agreed it's a long road to move them all over one by one, and I'm not sure of any more systematic way.
I've added a section to the epic/evergreen description "Ticket Tracker for Individual Errors to Improve" where folks can call out individual errors as they come across them.
Tip: when picking up a new ticket, start from the bottom b/c those are the newest ones and thus more likely to be low-hanging fruit/easy to tackle.
Short Term Objectives
Long Term Objectives
UnstructuredSQL errors and the use ofanyhow::Errorin any code that's part of the core database engine (see larger discussion here https://github.com/MaterializeInc/materialize/discussions/5340)