Hi Robert, thanks for alerting me to the 'mentions broken because of spaces issue'. Regarding your question, "I understand that categorial representations for SQL might help getting types to work to help get better programs in the end. I would love to hear a bit about motivations and lessons from applying these more modern approaches in practice, and I think the others might have more questions.", David and I and others examined this question in the paper 'Algebraic Databases': https://arxiv.org/pdf/1602.03501.pdf and from a purely syntactic view in 'QINL: co-LINQ, or Query Integrated Languages': https://arxiv.org/pdf/1511.06459.pdf . Basically, you have the same schemas as categories idea as usual, but you allow edges between the nodes in your category presentation that correspond to functions on types, e.g., reverse : String -> String or not : Bool -> Bool (and higher-arity generalizations thereof). In practice, rather than representing these functions extensionally, as infinite tables, you represent them intensionally as e.g., the SQL function 'reverse'.